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Abstract 



This document describes the attended installation and maintenance for OS/2 
V2.0 using redirected input/output on LAN-based client/server systems and 
response file or dialog techniques. It provides explanations, guidelines and 
practical hints on how to get access to redirected drives and how to install the 
OS/2 V2.0 using the dialog or response file interface. 

This document is intended for workstation specialists and system technical 
personnel responsible for mass-distribution of OS/2 V2.0. A knowledge of LAN 
redirection principles and Operating System/2 is assumed. 
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Preface 



This document is intended to show how the OS/2 V2.0 can be delivered 
electronically on LAN-based client/server systems using redirected input/output, 
dialog and response file techniques. 

It contains practical results of the OS/2 V2.0 installations and maintenance. 

This document is intended for IBM systems engineers and customer's technical 
personnel dealing with mass distribution and maintenance of Operating 
System/2 Version 2.0. 

A knowledge of Operating System /2 is assumed. 

The document is organized as follows: 

• Chapter 1, “Overview” 

An overview of distribution methods for PWS LAN environments. 

• Chapter 2, “Redirected Input/Output and Response Files” 

This provides a description of redirected input/output using a response file 
interface. 

• Chapter 3, “Installation Guidelines” 

This chapter describes the guidelines for remote installation from the 
different platforms, (brand new machine, DOS, OS/2 1.3 and OS/2 V2.0). 

• Chapter 4, “Remote Installation Utilities" 

This chapter describes the utilities that are provided by OS/2 V2.0 for the 
preparation for remote installation. 

• Chapter 5, “IBM LAN Client/Server Solution" 

This provides a description on the use of RIPL for remote installation. 

• Chapter 6, “TCP/IP Client/Server Solution” 

This chapter provides a description on how TCP/IP can be used for remote 
installation. 

• Chapter 7, “Novell Netware Client/Server Solution" 

This chapter provides a description on how the Novell Requester is used to 
perform a remote installation. 

• Chapter 8, “Alternative Methods to Install OS/2 V2.0 Remotely” 

This provides a description on alternative ways of installing OS/2 V2.0. 

• Chapter 9, “OS/2 V2.0 System Maintenance” 

This chapter describes the maintenance of OS/2 V2.0. 
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Chapter 1. Overview 



The growth in the use of programmable workstations over recent years was 
initiated by several factors: 

• The announcement of System Application Architecture* (SAA)* 

• Co-operative and distributed processing 

• Downsizing of the host environment 

• The announcement of OS/2* with the graphical user interface provided by 
Presentation Manager. 

The outcome has led to a growth in both host and LAN connectivity, with a 
proportional increase in the need for system and network management. 

In large environments distribution of programmable workstation application 
software, data, operating systems and its integrity is a growing concern. 

There are various methods for the distribution of programmable workstation 
application software and operating systems. The performance implications due 
to the load on the central processing unit and network lines have led to the need 
for a LAN-based client/server solution as follows: 

• "Home-grown" solutions 

• Using redirected input/output on LAN-based client/server systems 

• LAN Download Utility* {as part of NetView Distribution Manager/2’). 

This publication describes how an administrator can use a redirected drive to 
manage OS/2 V2.0 installation and maintenance remotely, without the need to 
feed sets of diskettes, answer questions during installation, or be dependent on 
a host connection. 

Remote Installation and Maintenance for OS/2 V2.0 is planned to be one book in 
a series covering all aspects of OS/2 V2.0* remote installation, in LAN and host 
environments. 



1.1 Sample Installation Code Diskette 

A diskette is distributed together with this document. Many REXX procedure 
samples listed throughout the book are collected on the diskette. It also supplies 
the reader with source and executable code of the multiple printer installation 
program and the source and executable code for the program that creates 
environment variables. See Appendix J, “Sample Installation Code Diskette" on 
page 217 for the contents of the diskette. 

This diskette is referenced throughout this book as the Sample Code Disk. 
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Chapter 2. Redirected Input/Output and Response Files 



This chapter introduces the concept of redirected input/output (I/O), and how 
redirected I/O can be used for the distribution and maintenance of OS/2 V2.0 to 
multiple workstations. 



2.1 Introduction 



Redirected I/O defines the capability of OS/2 V2.0 to use drive letters that are not 
connected to local drives (neither logical nor physical) but to drives, directories 
or subdirectories on a remote workstation. OS/2 V2.0 can be installed from any 
drive letter. 

Throughout this document the workstation where the redirected drive resides 
will be known as the server and a target workstation known as a client. 

A regular OS/2 V2.0 diskette installation is started from drive A: by inserting the 
"OS/2 V2.0 Installation" diskette into the drive and turning on the workstation. It 
will continue to install from drive A: until all diskettes required to install OS/2 
V2.0 have been fed into the diskette drive A:. 




Figure 1. OS/2 V2.0 System Image Distribution Using a Redirected Drive 



Depending on the transport system, there are different ways to establish a 
connection to a server and start a drive redirection. This publication describes 
several different ways by using: 

• IBM LAN Server for Remote Initial Program Load (RIPL”) 

• TCP/IP 

• Novell** Netware**. 

Depending on the method used, different preparatory actions are needed to 
establish a redirected drive connection. Three chapters of this publication 
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describe how a redirected drive can be accessed through the above-mentioned 
methods. 

All descriptions are based on IBM token-ring technology, NETBIOS, Novell IPX or 
TCP/IP protocols. If the network utilizes other LAN hardware, corresponding 
drivers are needed to establish hardware connections and low-level protocols. 

One or multiple workstations have to be assigned as the servers, distributing 
OS/2 V2.0 files. The server has a directory storing OS/2 V2.0 installation diskette 
images, and another for the corrective service diskettes (CSD) images. 

The client workstations will access the drive on the server where the diskette 
images reside, and will perform the installation. 

In installation scenarios involving multiple partitions on one hard disk or a Boot 
Manager installation, please refer to Appendix D, “Description of FDISK 
functions” on page 151. 

All installation suggestions follow the same basic concept using two diskettes, 
called "Installation" and "Diskette 1". To initiate the installation: 

• Place the "Installation" diskette into drive A: and boot 

• Upon request place "Diskette 1" into drive A: and press Enter. 

OS/2 V2.0 installation will automatically proceed from this point. 

Throughout this book "Diskette 1" for remote installations is called "LT diskette" 
(LAN Transport diskette). This is done to avoid confusion between the original 
"Diskette 1" from OS/2 V2.0 and the remote installation diskette 1. 

This "LT diskette" needs to hold only minimal required OS/2 V2.0 executables, 
LAN driver support and the appropriate code to establish a communication with 
a server. 

This LT diskette is created in two steps: 

1. Use the program SEDISK to create OS/2 V2.0 basis 

2. Add the corresponding redirected I/O feature. 

How to create the OS/2 V2.0 basis is described in 4.1.2, “SEDISK” on page 19. 
How to add the redirected I/O feature is described for all the above-mentioned 
methods in the corresponding chapters under the subheading "Preparation of the 
LT diskette". This does not apply to the IBM LAN Server RIPL method. 



2.2 Attended Redirected Installation 

This document discusses two types of redirected installations: 

• Dialog-driven installation 

• Response file installation 

The attended dialog-driven installation is a special version of a regular OS/2 V2.0 
installation. It utilizes the same installation program (SYSINST2.EXE) but 
accesses a redirected drive, which takes away the need to feed diskettes. All 
questions asked by the installation procedure must be answered before the 
program will continue the installation. This is described in detail in 8.1, 
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“Attended Dialog-Driven Installation” on page 105 and 4.2.3, “SYSINST2” on 
page 22. 
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Figure 2. Redirected I/O Dialog Driven Installation Flow. This diagram graphically shows 
the steps of a dialog-driven installation. 



The attended response file installation utilizes a different installation program 
(RSPINST.EXE). This program reads a file called response file, interprets its 
contents, connects to the redirected drive and then automatically installs without 
any further interruption. 
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2.3 Response Files 

This section outlines an overview of response files and how these files provide 
the necessary configuration information required for operating system 
installations. 

2.3.1 Why Response Files? 

The basic installation process requires inserting diskettes and answering screen 
prompts to provide configuration information. When response files are used it is 
not necessary to answer any prompts, as all the information is provided by the 
response file. 

2.3.2 Response File Overview 

The response file interface effectively turns off the user interface. With the 
exception of a progress indicator, no panels will be presented to the user. 

The response file will contain the necessary information for workstation 
configuration. Response files consist of many different Keywords, which are 
described in Appendix A, “Response File Keyword Reference, Samples And 
Details” on page 117. 

The installation and maintenance process uses a different type of response file. 
More information on response files used by the maintenance process is 
documented in Chapter 9, “OS/2 V2.0 System Maintenance" on page 109. 

The multiple printer installation also uses a response file. The Keywords for this 
file are described in Appendix G, “Printer Response File Keyword Definition and 
Sample” on page 165. 

2.3.3 Response File Processing 

Response files can only reside on the server workstation. The SET OS2_SHELL 
statement in CONFIG.SYS on the LT diskette specifies the response file location 
for the remote installation. 

In the following example of a response file installation, OS2SE20.RSP is the 
response file that will be used. It resides on the redirected drive Z: on the server 
workstation. 

SET 0S2_$HELL=Z : \rspi nst . exe Z:\os2se20.rsp 

When the response file is found, it uses the configuration information as input for 
the OS/2 V2.0 installation process. 

Once the response file is processed, the initial full screen portion of OS/2 
System Installation will continue to copy all diskette images from the server 
machine. Upon reboot the Installation will be complete. 

The same rules apply for the maintenance response file. 

On the other hand the multiple remote printer installation response file is called 
via a user exit of the installation response file. 

Any erroneous Keyword in response files are ignored by the installation process. 
The entire installation will be recorded in a log file. 
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Figure 3. Redirected I/O Response File Installation Flow. This diagram graphically 
shows the steps of a response file installation. 
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Chapter 3. Installation Guidelines 



This chapter describes the installation guidelines necessary to install or upgrade 
the following environments to OS/2 V2.0: 

1. Workstations with no operating system installed 

2. Upgrading DOS Systems to OS/2 V2.0 

3. Upgrading OS/2 VI. 3 to OS/2 V2.0 

4. Upgrading pre-release OS/2 V2.0 to OS/2 V2.0. 

It is assumed that the reader has completed the following steps: 

1. The server has been prepared 

2. The OS/2 installation diskette images have been copied to a directory on the 
server machine 

3. The response files have been prepared for the client workstations 

4. The LT diskettes have been prepared for the client workstations 

5. Clients can access all required redirected drives. 

Note: 

Each of the above steps is described in detail in the following chapters: 

• Chapter 5, “IBM LAN Client/Server Solution” on page 23 

• Chapter 6, “TCP/IP Client/Server Solution" on page 35 

• Chapter 7, “Novell Netware Client/Server Solution” on page 65. 



3.1 Hardware Requirements for Client Workstations 

Minimum requirements for installing OS/2 V2.0 using redirected I/O: 

1. 386SX or higher processor 

2. 40 MB fixed disk 

3. 18 MB free space 

4. 6 MB memory 

5. The client must be on the same logical LAN as the server 

6. The installation and LT diskettes. 



3.2 Workstation with No Operating System 

The following section provides installation guidelines when installing OS/2 V2.0 
on a workstation that either needs the hard disk partitioned or has no operating 
system installed. 
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3.2.1 Default Response File Installation 

The default installation process uses the response file interface to check the 
status of the target drive specified in the response file. 

Depending on the result of this check, different procedures are taken by the 
installation process: 

• If the hard disk is not partitioned 

The installation process creates one large partition on the disk. 

Note: If the target drive is set to any drive letter other than C:, the 
installation process will produce an error and will not continue. 

» If hard disk has been partitioned 

The installation process will check the size of the target drive, making sure 
the that the size of the partition is greater than: 

— 18 MB for the minimum options installation. 

If the hard disk needs to be partitioned use the technique described in 
Appendix F, “Automating Fixed Disk Partitioning" on page 159. 

3.2.2 Installation Procedure 

Once it has been decided how the disk(s) are going to be partitioned the 
installation process can proceed as follows: 

Perform the following steps in order to initiate the installation process: 

1. Ensure the server and client workstations are prepared 

2. If hard disk partitioning is required make sure the partition size is set 
correctly in the REXX code. 

3. Server must be active 

4. The client workstation(s) must be rebooted with the first install diskette 

5. When prompted insert the LT diskette and press Enter. 

Once the Enter key has been pressed, the installation (including any partitioning) 
will commence. The operating system will be installed on the client 
workstation(s). 



3.3 Upgrading DOS Systems to OS/2 V2.0 

This following section provides installation guidelines when upgrading existing 
DOS systems to OS/2 V2.0. 

A brief overview on OS/2 V2.0 features will be covered for the benefit of the 
previous DOS users. An explanation on the dual boot feature will be provided, 
plus a description of the procedure when migrating DOS Windows applications to 
OS/2 V2.0. 
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3.3.1 Introduction to Dual Boot 

Dual boot was first introduced in OS/2 1.2. Users with programs, that would not 
run in the DOS box provided with OS/2 1.3 could boot with a native DOS system 
to run their DOS applications. This same feature is now available under OS/2 
V2.0. 

Below is a brief description on how the dual boot feature works. 

In an existing OS/2 environment the command to boot DOS is: 

BOOT /DOS 

The system will answer: 

SYS1714 Warning! Hake sure all your programs have completed 
or data will be lost when the system Is restarted. 

You requested to start 00S from drive C:. 

Your system will be reset. Do you want to continue (Y/N)? 

if Y is entered, the system will display the following messages 

The hard disk is being prepared. Please wait.... 

and automatically reboot with the previously installed DOS. This environment 
will be identical to the environment before the installation of OS/2 V2.0, 
assuming the original DOS was left on the partition before installing OS/2 V2.0. 

If the user wants to get back to the OS/2 he enters: 

C:\0S2\B00T /0S2 
The system will answer: 

SYS1714 Warning! Make sure all your programs have completed 
or data will be lost when the system Is restarted. 

You requested to start DOS from drive C:. 

Your system will be reset. Do you want to continue (Y/N)? 

if Y is entered, the system will display the following messages 

The hard disk is being prepared. Please wait.... 

and automatically reboot under OS/2 using the initial settings. 

Depending on the environment the user is currently using the directory 
C:\OS2\SYSTEM will have different files stored. 

While the DOS environment is active the following files will reside in this 
directory: 

C:\0S2\SYSTEH\BC0T.0S2 
C : \0S2\SYSTEM\C0NFIG. 0S2 
C : \0S2\SYSTEH\AUT0EXEC . 0S2 

On the other hand while the OS/2 environment is active the following files will 
reside in this directory: 

C:\OS2\SYSTEM\BOOT.DOS 

C:\0S2\SYSTEH\C0NFIG.D0S 

C:\0S2\SYSTEM\AUT0EXEC.D0S 

When the boot command changes the environment from DOS to OS/2 it does the 
following: 
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1. CONFIG.SYS and AUTOEXEC.BAT are saved into the C:\OS2\SYSTEM as 
CONFIG. DOS and AUTOEXEC.DOS. 

2. CONFIG.OS2 and AUTOEXEC.OS2 are copied back into the C: root directory 
as CONFIG.SYS and AUTOEXEC.BAT. The two files are deleted in 
C:\OS2\SYSTEM . 

3. The DOS boot record is copied to C:\OS2\SYSTEM as BOOT.DOS. 

4. The BOOT.OS2 is copied into the boot record area and deleted from 
C:\OS2\SYSTEM. 

5. The system then automatically reboots. 

Note: None of the above-mentioned files should ever be deleted from the 

system. 

3.3.2 Basic Preparations for Dual Boot 

In order to have a fully functional dual boot system, the workstation will need 
some preparatory work prior to the OS/2 V2.0 installation. 

First of all the following statement needs to be in the DOS CONFIG.SYS: 

SHELLAC: \D0S\C0HMAND . CON 

The AUTOEXEC.BAT needs the following: 

SET C0HSPEC°C: \D0S\C0MMAND. COM 

Although these statements may be new to the DOS user, they are necessary, 
because the DOS COMMAND.COM file will be deleted from the C: root directory 
when OS/2 V2.0 is installed. The DOS system therefore needs an indication 
where to find its command processor. 

| Note — 

These statements need to be included before OS/2 V2.0 is installed. 



3.3.3 Confirmation of Dual Boot Installation 

If the dual boot feature was installed successfully the following message will 
appear in the INSTALL.LOG: 

Dual boot feature installed 

If the dual boot feature was not successfully installed, the following message will 
appear: 

No Dual boot feature installed 

The reason being that either the C: drive is formatted during the install process, 
or no DOS environment is located in a C:\DOS directory on drive C:. If the 
SHELL = statement mentioned above is missing, the INSTALL.LOG will produce 
an error messages and dual boot will not work. 
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3.3.4 Boot Manager 

Boot Manager is a feature used under OS/2 V2.0 that allows several primary and 
logical partitions on one system. It also provides the capability of booting from 
any of these primary or logical drives, should the installed operating system 
support this function, such as OS/2 V2.0 does. One of these primary partitions 
(the first one on the first physical disk) could be a DOS system. Boot Manager 
does however require a 1MB partition on the first physical disk. See 
Appendix C, "Partitioning of Physical Disks” on page 145 for additional 
information on the use of Boot Manager. 

3.3.5 OS/2 V2.0 and Windows 

For more precise information on Windows** please refer to OS2 Version 2.0, 
Volume 2: DOS and Windows Environment and for migration purposes to 
Migrating from a DOS/Windows Environment to OS/2 V2.0, Porting Windows 
Applications to OS/2 V2.0. 

These two documents describe in great detail how DOS and Windows 
applications can be migrated from their original environment to an OS/2 V2.0 
VDM. 

The following section gives a brief overview over the power of OS/2 V2.0 VDMs 
and which types of Windows environments are covered by OS/2 V2.0. 

OS/2 V2.0 provides the capability for Microsoft** Windows applications to run 
under OS/2 V2.0. This support allows applications written for Windows 3.0 and 
previous versions of Windows to coexist and execute in the same workstation 
under OS/2 V2.0. 

Each Windows application executes in its own VDM. As such, Windows 
applications are subject to the same application protection facilities provided to 
other protected mode applications under OS/2 V2.0. Windows applications are 
protected from other Windows applications and from DOS and OS/2 applications 
executing in the system. This is in contrast to the native Windows 3.0 
environment, where protection is limited to Windows 3.0 applications only. 

The execution of Windows applications as protected mode tasks also allows 
these applications to take full advantage of the pre-emptive multitasking 
capabilities of OS/2 V2.0, with full pre-emptive multitasking between Windows 
applications, OS/2 applications and DOS applications. 

This is again in contrast to the native Windows 3.0 environment, where 
pre-emptive multitasking is available only when Windows 3.0 is running in 
enhanced mode, thereby impacting performance and preventing many 
applications written for previous versions of Windows from executing. 

OS/2 V2.0 has no such restriction. Windows applications running under OS/2 V2.0 
will run in a mode equivalent to the real or standard modes of Windows 3.0. The 
enhanced mode of Windows 3.0 is not required since OS/2 V2.0 operating system 
itself provides equivalent function. 

As far as OS/2 V2.0 is concerned, Windows applications are just a special case 
of DOS applications, which need a special environment (Windows 3.0) to run. 
Therefore the key to Windows application compatibility is to provide those 
applications with as similar an environment as possible to that experienced 
under DOS, while taking advantage of the inherent design superiority of OS/2. 
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3.3.5.1 Different Windows Modes 

First of all, it should be understood that the Windows 3.0 shrink-wrapped retail 
package can be run in a Virtual DOS Machine(VDM) in real mode, and Windows 
applications are started from within this VDM by the Windows Program Manager. 
It cannot be run in standard or enhanced mode because of Windows' memory 
management. Real mode is fully supported under OS/2 V2.0. 

Standard mode is needed for some Windows applications. To accommodate 
these applications, OS/2 needs to provide additional support. Basically these 
applications need to access DOS Protect Mode Interface (DPMI) services for 
extended memory support. 

OS/2 will support Windows applications running in standard mode in a VDM. The 
use of the VMD design, which provides a self-contained DOS environment, 
means that the environment is identical from the applications point of view. 

3.3.5.2 Single and Multiple Windows Application Sessions 

A single application Windows session is the recommended way of running 
Windows applications under OS/2. Since the application runs in a self-contained 
Windows environment in its own VDM, it is fully protected from other 
applications and the system is protected from it. The application is loaded from 
the PM shell in a very similar way to a DOS application, and can switch back to 
PM easily, as well as share data via clipboard or dynamic data exchange (DDE) 
with other Windows applications or PM applications. 

The multiple-application Windows session is almost exactly the same as running 
Windows 3.0 on a DOS machine today. It even uses the Windows 3.0 Program 
Manager to start multiple Windows applications within the same VDM. It 
therefore provides maximum "look and feel" compatibility for DOS/Windows 
users migrating to OS/2. It is a requirement where Window applications need to 
communicate with each other via shared memory. 

In conclusion, most of the Windows programs that ran on Windows before will 
continue to run successfully under OS/2 V2.0. Some restrictions may apply as 
seen above, but the conversion from DOS to the most DOS-like view of a 
multiple application Windows should run immediately without any problems. 

3.3.6 The Installation Process 

Perform the following steps in order to initiate the installation process: 

1. Ensure preparatory steps are complete 

2. Ensure the server has been started 

3. The client workstation(s) must be rebooted with the first install diskette 

4. When prompted insert the LT diskette and press Enter. 

Once the Enter key has been pressed, the OS/2 diskette images will be 
transferred from the server to the client workstation(s). 
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3.4 Upgrading OS/2 Version 1.X to OS/2 V2.0 

The following section provides installation guidelines when upgrading existing 
OS/2 1.X systems to OS/2 V2.0. 

The response file interface follows the procedure listed below: 

• System directories and files not used by OS/2 V2.0 will be deleted from the 
system. 

• If duplicate system files are found, they will be replaced by the 2.0 versions. 

• OS/2 V2.0 has additional directories and system files that are not used by 
OS/2 VI. 3. These directories will be created and the necessary system files 
copied into them. 

If a workstation supported the dual boot feature, and the user wanted DOS to 
remain on the system, the Keyword FormatPartition=0 should be used. The 
disk will not be formatted during the installation process, leaving the DOS files in 
place. 

3.4.1 Installation Process 

Perform the following steps in order to initiate the installation process: 

1. Ensure preparatory steps are complete 

2. Ensure the server has been started 

3. The client workstation(s) must be rebooted with the first install diskette 

4. When prompted insert the LT diskette and press Enter. 

Once the Enter key has been pressed, the OS/2 diskette images will be 
transferred from the server to the client workstation(s). 



3.5 Upgrading Pre-release OS/2 V2.0 to OS/2 V2.0 

The following section provides installation guidelines when upgrading existing 
OS/2 V2.X system to a current release of OS/2 V2.X. 

The response file interface follows the procedure listed below: 

• OS/2 V2.0 pre-release installed system directories and files not used by the 
current version of OS/2 V2.0 will be deleted from the system 

• If duplicate system files are found, they will be replaced by the 2.0 versions 

• Any additional system directories will be created and the necessary files will 
be copied into them. 

It is recommended that the FormatPartition = 1 (format disk) Keyword is used 
when upgrading from a pre-release version of OS/2 V2.0 to OS/2 V2.0. 

3.5.1 Installation Process 

Perform the following steps in order to initiate the installation process: 

1. Ensure preparatory steps are complete 

2. Ensure the server has been started 

3. The client workstation (s) must be rebooted with the first install diskette 
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4. When prompted insert the LT diskette and press Enter. 

Once the Enter key has been pressed, the OS/2 diskette images will be 
transferred from the server to the client workstation s). 
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Chapter 4. Remote Installation Utilities 



This chapter describes several programs that are included in OS/2 V2.0 that are 
useful to administrators setting up remote installation of OS/2 V2.0. These 
utilities are: 

• The CID (Configuration Installation Distribution) file 

• The response file installation program RSPINST.EXE 

• The sample response file SAMPLE. RSP 

• The standard dialog-driven installation program SYSINST2.EXE. 



4.1 The CID File 



Four programs are shipped with OS/2 V2.0 to assist administrators with remote 
installation of the system. These programs are packaged in a bundle file shipped 
on Diskette 7 of the OS/2 V2.0 package. The programs are: 

• SEIMAGE.EXE 

• SEDISK.EXE 

• SEMAINT.EXE 

• SEINST.EXE 

These files will not be installed as part of a normal OS/2 V2.0 installation, but 
must be manually unpacked from Diskette 7. The bundle file on Diskette 7 is 
called CID. To unpack the files: 

1. Open an OS/2 command prompt 

2. Insert Diskette 7 in drive A: 

3. Type “UNPACK A:CID” 

4. The files will be unpacked to the \OS2\INSTALL subdirectory of your fixed 
disk. ' 

| Notes on UNPACK 

This file may only be unpacked using the OS/2 V2.0 UNPACK.EXE. You may 
execute UNPACK.EXE on an OS/2 1.3 or DOS system provided you have 
copied the program from an OS/2 V2.0 system, or OS/2 V2.0 Diskette 2. 

If you do not wish to unpack the files to the \OS2\INSTALL subdirectory, you 
may provide the target directory as a parameter to UNPACK. 

UNPACK A:CID C:\TEMP 

If you wish to unpack only one of the files, you may use the /n parameter of 
UNPACK. 

UNPACK A: CID C:\TEMP /n: SEIMAGE.EXE 

Refer to the OS/2 Command Reference for full details of the OS/2 V2.0 
UNPACK command. 
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4.1.1 SEIMAGE 



SEIMAGE.EXE is a utility to automate the creation of a subdirectory structure on 
the installation server, for use by the remote installation process. SEIMAGE 
copies all OS/2 V2.0 diskettes to a specified target directory. The diskettes are 
copied into directories with the same name as their volume labels. For example, 
volume label "DISK 0” will be copied into a DISK_0 subdirectory within the 
specified target directory. Directories are created by SEIMAGE if they do not 
exist. The program will prompt the user to insert diskettes and copy all files from 
the diskettes to the appropriate directories. SEIMAGE may be executed from an 
OS/2 V2.0 or OS/2 VI. 3 command prompt. 

The output of the SEIMAGE program is a directory structure suitable for use by 
the installation programs RSPINST.EXE or SYSINST2.EXE (See section 4.2, 
“Installation Programs" on page 21 for more details). 

Syntax of the SEIMAGE program is: 

SEIMAGE /S:< drive > /T: < drive >< path > 

/S = source drive. This is the diskette drive from which the OS/2 V2.0 
diskettes will be loaded. 

/T = target directory. This is the fully qualified target directory name. This 
directory will be shared and become the source path for installation by 
RSPINST.EXE or SYSINST2.EXE. 

Example: SEIMAGE /S:A: /T:D:\OS2SE20 

This will install from diskettes in the A: drive to a directory structure under 
D:\OS2SE20. The following figure shows the directory structure that will be 
created. 



L OS2SE20V 
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DISK.3 
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PMDD.2 
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Figure 4. SEIMAGE Directory Structure 
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4.1.2 SEDISK 



SEDISK.EXE is a utility that will create the installation diskette (DISK_0) and 
Diskette 1 {DISK_1) of OS/2 V2.0. The diskettes as created have no LAN 
Transport drivers or redirector code. This must be manually added depending on 
the requirements of your particular installation (see 6.3.3, “Preparation of the 
NFS Client LT Diskette” on page 40 and 7.3.3, “Preparation of the Novell LT 
Diskettes" on page 72 for examples). SEDISK requires two formatted diskettes 
and also requires that the diskette images have previously been installed on the 
hard disk (using SEIMAGE). SEDISK may be executed from an OS/2 V2.0 or OS/2 
VI. 3 command prompt. 

Syntax of the SEDISK program is: 

SEDISK /S:<source path> /T: < target drive > 

/S = fully qualified path to the OS/2 V2.0 diskette images. This can be a 
local hard drive or redirected drive. 

/T = target drive name. 

Example: SEDISK /S:D:\OS2SE20 /T:A: 

This command will create the two OS/2 V2.0 bootable diskettes from files in the 
d:\OS2SE20 subdirectory. 



4.1.3 SEMAINT 

SEMAINT.EXE is intended to install a minimal OS/2 V2.0 “seed” system on the 
target machine. By booting from the seed subdirectory structure the normal 
system files will not be locked, allowing system or CSD installation. SEMAINT is 
also useful for disketteless upgrade of existing systems. See 6.6, “Disketteless 
Upgrade of OS/2 VI. 3 TCP/IP Workstations" on page 58 and 7.5, “Disketteless 
Upgrade of OS/2 1.3 for Novell workstations" on page 96 for some examples. 

SEMAINT is included in OS/2 V2.0 for use in future product implementations. 

Syntax of the SEMAINT program is: 

SEMAINT /S:<source path> /T:< target directory > /B:<boot drive > 

/L1:<path> dog file name> 

/S = fully qualified path to the OS/2 V2.0 diskette images. This can be a 
local hard drive or redirected drive. 

/T = fully qualified target directory name. The seed OS/2 V2.0 system will be 
installed under this directory. The target directory must be on a local drive. 

/B = target boot drive. The drive from which the seed system will boot. The 
drive specified must be a local drive. 

/LI = fully qualified name of the file into which log information is to be 
placed. The directory in which the log file is to be placed must already exist. 

Example: SEMAINT /S:Z:\ /T:C:\maint /B:C: /L1:C:\maint.log 

This command will install a bootable OS/2 V2.0 maintenance system under the 
C:\MAINT directory, using files from the redirected Z: drive, and writing a log file 
C:\MAINT.LOG. 
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i Note 



If you are using SEMAINT on an OS/2 VI .3 system to install an OS/2 V2.0 
seed system, it is advisable to make a copy of the OS/2 1.3 root directory 
before using SEMAINT (For example, COPY C:\V C:\ROOT\V). The OS/2 
VI. 3 system can then be recovered by the following steps: 

1. Boot from an OS/2 VI. 3 Install diskette 

2. Press ESC at the first screen to obtain a command prompt 

3. ERASE C:\V 

4. COPY C:\ROOT\V C:\V 

5. Restore the original CONFIG.SYS, STARTUP.CMD, and AUTOEXEC.BAT 
which have been saved as *.S13 files in the target directory 

6. SYSINSTX C: 

7. Remove the diskette from Drive A: and reboot. 



4.1.4 SEINST 

SEINST.EXE is intended to install OS/2 V2.0 on the target machine. SEINST runs 
RSPINST.EXE, but accepts parameters in a different format and will perform 
some cleanup related to SEMAINT. 

Note 

SEINST is included in OS/2 V2.0 for use in future product implementations. 

RSPINST is used for most response file installations in this book, except 
disketteless upgrades from OS/2 VI. 3, which uses SEINST. 



SEINST relies on an environment variable called REMOTEJNS TALLJS TATE. If 
REMO TEJNSTALLJS TATE=0, SEINST will restore the CONFIG.SYS, 
AUTOEXEC.BAT, and STARTUP.CMD of the workstation (which are saved as 
CONFIG.S13, AUTOEXEC.S13, and STARTUP.S13 by SEMAINT) before calling 
RSPINST. 

This feature allows you to use SEMAINT to create a seed system, but still 
migrate the workstation's original CONFIG.SYS, AUTOEXEC.BAT, and 
STARTUP.CMD (not the ones created by SEMAINT). This function of SEINST is 
used in 6.6, “Disketteless Upgrade of OS/2 V1.3 TCP/IP Workstations” on 
page 58 and 7.5, “Disketteless Upgrade of OS/2 1.3 for Novell workstations” on 
page 96. 

Other values of REMOTE JNSTALLJST ATE are reserved for future use. 

Syntax of the SEINST program is: 

SEINST IB: < boot drive > /T:<maint directory > /R: < path >< response file > 
/S:<source path > /L1:<path> <log file name> 

/ B = target boot drive. The drive from which the system will boot after 
installation. The drive specified must be a local drive. 
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/T = directory from which the system was booted. For example, A:\ if the 
system was booted from diskette, or C:\MAINT if booted from a seed system. 
SEINST will do some “cleanup" of this directory - beware! 

/R = fully qualified response file name. For example, A:\OS2SE20.RSP. 

/S = fully qualified path to the OS/2 V2.0 diskette images. This can be a 
local hard drive or redirected drive. 

/LI = fully qualified name of the file into which install log information is to 
be placed. 

Example: SEINST /B:C: /T:A:\ /R:A:\OS2SE20.RSP /S:Z:\ /L1:X:\INSTALL.LOG 

This command will install OS/2 V2.0 onto the C: drive, having booted from the A: 
drive. The response file to be used is A:\OS2SE20.RSP, and the source path for 
diskette images is the directory Z:\. A log file will be written to X:\INSTALL.LOG. 



4.2 Installation Programs 

The default OS/2 V2.0 installation diskettes are set up for a dialog-driven, 
diskette-based installation. OS/2 V2.0 provides alternate methods of installation, 
however. 



4.2.1 RSPINST 

RSPINST.EXE reads an ASCII response file containing all definition keywords 
instead of prompting the user via dialogs. 

RSPINST accepts a single parameter, which is the name of the response file to 
be used. 

RSPINST can be found in the OS2MNSTALL subdirectory of an installed OS/2 V2.0 
system, or may be directly unpacked from the REQUIRED file on Diskette 7. The 
following command will place RSPINST.EXE into the C:\TEMP directory, assuming 
OS/2 V2.0 Diskette 7 is in the A: drive. 

UNPACK A: REQUIRED C:\TEMP /n: RSPINST. EXE 

4.2.2 SAMPLE. RSP 

SAMPLE.RSP is an example ASCII response file for RSPINST. it can be edited 
with any ASCII editor. Administrators should start with SAMPLE.RSP and build 
the customized response files for their installations. 

Refer to Appendix A, “Response File Keyword Reference, Samples And Details” 
on page 117 for a detailed description of all keywords that are defined in the 
response file. 

SAMPLE.RSP can be found in the OS2MNSTALL subdirectory of an installed OS/2 
V2.0 system, or may be directly unpacked from the REQUIRED file on Diskette 6. 
The following command will place SAMPLE.RSP into the C:\TEMP directory, 
assuming OS/2 V2.0 Diskette 6 is in the A: drive. 

UNPACK ArREQUIRED C:\TEMP /n:SAMPLE.RSP 
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4.2.3 SYSINST2 



SYSINST2.EXE is the standard OS/2 V2.0 installation program. When used, it will 
perform the installation from diskette if there is no drive parameter used with it. 
This is the default. If it is passed a redirected drive as a parameter, SYSINST2 
will perform a dialog-driven installation from the redirected drive. See 8.1, 
“Attended Dialog-Driven Installation” on page 105 for examples of redirected 
SYSINST2 installation. 

SYSINST2.EXE will be found on OS/2 V2.0 Diskette 1. 
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Chapter 5. IBM LAN Client/Server Solution 



The purpose of the redirected I/O and response file capability provided with OS/2 
V2.0 is to simplify the installation of OS/2 V2.0 workstations. Redirected I/O 
removes the need to transport large numbers of diskettes to every workstation. 
Response files allow the administrator to control all facets of a workstation's 
installation without the user answering any questions about the installation. 

Refer to Chapter 2, “Redirected Input/Output and Response Files” on page 3 for 
more information. 

This chapter describes a method of obtaining a redirected drive letter for OS/2 
V2.0 installation, using IBM OS/2 LAN Server V2.0. 

The OS/2 V2.0 installation program RSPINST.EXE will only execute on an OS/2 
V2.0 system. This means that the workstation on which OS/2 V2.0 is to be 
installed must boot a usable OS/2 V2.0 system. If you wish to install from a 
server running OS/2 LAN Server, you need a way to attach a drive letter to an 
Alias on the server. The IBM OS/2 LAN Requester components LOGON, NET 
START, and NET USE require Presentation Manager present as well as many 
executable files. It is impossible to boot an OS/2 V2.0 LAN Requester system 
from a few diskettes. 

This problem was solved by using the Remote Initial Program Load (RIPL) 
feature of IBM OS/2 LAN Server V2.0. RIPL allows a requester to boot from an 
OS/2 V2.0 directory structure on the server. The workstation sees its boot drive 
(Z:, corresponding to an area on the LAN Server) as well as the local drive(s). 
Since the system has booted OS/2 V2.0, and has access to both a redirected 
drive on a server and the local drive, OS/2 V2.0 can be installed on the local 
drive using the standard remote install procedure outlined in Chapter 2, 
“Redirected Input/Output and Response Files” on page 3. 



5.1 Overview of Remote I PL 

RIPL is the process of downloading IPL files from a server to a workstation in 
order to start (boot) the workstation. You should review IBM Operating System/2 
Local Area Network Server Version 2.0 Network Administrator Reference Volume 
3, S04G-1034, particularly the sections on RIPL, before continuing. 

RIPL can be used to boot OS/2 V2.0 on a workstation with DOS or OS/2 VI. 3 
installed on the fixed disk, on a machine with an unformatted fixed disk, or a 
machine with no fixed disk at all! Normally to enable a workstation to RIPL from 
a server, the LAN adapter in the workstation must be enabled with a RIPL ROM 

module. 

— Important Note! — 

A RIPL ROM module is not required for installation if you are using a 
token-ring LAN. IBM OS/2 LAN Server V2.0 includes a productivity aid called 
RPLDISK. This utility will build a bootable diskette which simulates the code 
in the RIPL ROM module. See section 5.3.2, “Preparation of the RIPL 
Installation Diskette” on page 30 for detailed information. 
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Note: The newest IBM Token-Ring Adapters {P/N 74F9410) and the IBM PS/2 
Adapter/A for Ethernet Networks have the RIPL ROM included as standard. 
Clients with IBM PC Network adapters must be configured for Remote I PL (they 
include the RIPL hardware). Older token-ring dapters must have a RIPL ROM 
installed, or use the RPLDISK utility. Refer to the documentation that came with 
your network adapter or RIPL module for more information. 

Note that there is no support in OS/2 LAN Server V2.0 for RIPL from a non-IBM, 
AT Bus Ethernet adapter. 

The RIPL ROM works by adding itself to a machine's boot sequence. A 
workstation with RIPL capability will normally attempt to IPL in the following 
sequence: 

1. From diskette if a bootable diskette is in the drive 

2. From fixed disk if the drive is bootable 

3. From the RIPL server. 

Note: Some PS/2 systems allow the user to redefine this boot sequence through 
the use of the Reference Diskette. 

If a workstation reaches Stage 3, or if it was booted with a RPLDISK diskette in 
Stage 1, it will broadcast a RIPL request on the LAN. An IBM OS/2 LAN Server 
V2.0 server with the RemoteBoot service active will respond if the workstation's 
LAN adapter address has been defined to that server. From this point on the 
workstation will perform a normal OS/2 V2.0 IPL from a subdirectory structure on 
the server. 



5.2 RIPL Installation Scenarios 

There are several possible workstation configurations for machines that are to 
be installed with OS/2 V2.0: 

• New machine, unformatted hard disk 

RIPL is ideal in this situation. Connect the machine to the LAN and power it 
on. Since it cannot boot from the hard drive the machine will RIPL and run 
the OS/2 V2.0 installation procedure. At the completion of the install the 
workstation reboots as a totally functional OS/2 V2.0 system. 

• Existing DOS or OS/2 machine 
— Token-Ring LAN 

Create a diskette using the RPLDISK utility of IBM OS/2 LAN Server V2.0. 
Boot the client from this diskette and the machine will RIPL and run the 
OS/2 V2.0 installation procedure. At the completion of the install the 
workstation reboots as a totally functional OS/2 V2.0 system. 

— Non Token-Ring LAN 

In this situation RIPL capability must be available in your adapter. 

Also, the fixed disk must be disabled so it will not boot and the machine 
will RIPL. IBM OS/2 LAN Server V2.0 provides a utility for this purpose, 
called RPLENABL.EXE. This is a DOS program which is located in the 
RPL\DOS subdirectory of the Remote IPL server. It disables the fixed 
disk of the workstation (without affecting the contents) and enables RIPL 
from the workstation. This utility must be run from a diskette which has 
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booted DOS, it will not run under OS/2. The OS/2 V2.0 installation 
procedure will enable the fixed disk and disable RIPL, so that the 
machine will IPL from the local fixed disk when rebooted at the end of 
the installation procedure. For more information on RPLENABL, see 
Appendix C of IBM Operating System/2 Local Area Network Server 
Version 2.0 Network Administrator Reference Volume 3, S04G-1034. 

5.2.1 Overview of Installation Steps for RIPL 

An overview of the steps required is listed below. Each step is explained in 

detail in the next section, 5.3.1, “RIPL Server Preparation” on page 26. 

1. The administrator installs IBM OS/2 LAN Server V2.0 with OS/2 Remote IPL 
support on the server system. 

2. The administrator runs the RIPLINST utility to set up the directories on the 
server from which the clients will IPL. 

3. The administrator runs the SEIMAGE utility to set up the directories on the 
server from which the clients will install OS/2 V2.0 to their local fixed disks. 

4. The administrator runs the GETRPL utility to complete the IBM OS/2 LAN 
Server V2.0 Remote IPL configuration process. 

5. The administrator creates a master workstation definition, which will be used 
as a model for the definitions of client workstations. 

6. The administrator creates response files for the installation of the clients. 

See Chapter 2, “Redirected Input/Output and Response Files” on page 3 for 
more information on response files and the response file installation 
process. 

7. The administrator edits the master workstation File Index Table (FIT) file, and 
the master workstation CONFIGRI.20 file. 

8. The administrator creates workstation definitions for each of the client 
workstations to be installed, using the master workstation definition as a 
model. This requires entering a Workstation Name and LAN Adapter Address 
for each of the client workstations. 

9. The administrator edits the RPL.MAP file. 

10. The administrator starts the RemoteBoot service on the server. 

11. The administrator prepares an Installation diskette. This is a DOS diskette 
that is either prepared with the RPLDISK utility or one with RPLENABL.EXE. 
Copies of the Installation diskette are distributed to “installers.” 

12. The "installers” travel to each client system. 

13. At a client, an “installer” inserts the Installation diskette and reboots the 
client. If the Installation diskette was made with RPLDISK, the client will now 
RIPL from the server. 

14. If the Installation diskette used RPLENABL, the “installer” removes the 
diskette and reboots again. The client will now RIPL from the server. 

15. The client completes the OS/2 V2.0 installation process. 

16. At the completion of the installation process, the client is rebooted as a fully 
functional OS/2 V2.0 system. 
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I FIT Files 



The concept of File Index Table (FIT) files is very important to the 
understanding of IBM OS/2 LAN Server V2.0 Remote IPL. If you are not 
familiar with the concept, review the IBM OS/2 LAN Server V2.0 
documentation now, or the following sections may be confusing. 

For example, the client “sees” the following mapping of drives and 
directories to the server: 

Client drive Server directory 

Z:\ \IBMLAN\RPLUSER\“client name.” For example, from the 

Remote IPL Workstation called HORSE the Z:\ directory is 
\IBMLAN\RPLUSER\HORSE on the server. 

Z:\OS2\INSTALL \IBMLAN\RPL\OS2.20\OS2\INSTALL 

Z:\OS2INST \IBMLAN\RPL\OS2INST 

As you can see, RIPL does not use a “normal” mapping of client drives and 
directories to server directories. 



5.3 Basic RIPL Installation Scenario 

This section describes the steps required to set up an OS/2 V2.0 installation 
system. The following assumptions are made for this scenario: 

• The fixed disks of the clients are already partitioned as required. 

• The administrator has prepared a response file called INSTALL.RSP which 
defines the installation parameters for all clients. 

• Logs of the installation process will not be collected to a central point, but 
will reside on each client. 

• OS/2 V2.0 base system only will be installed. 

For a more advanced scenario, which includes client fixed disk partitioning, 
individual response files for each client, and central collection of installation logs 
to the server, see section 5.4, “Advanced RIPL Installation Scenario” on 
page 31. 

Time Saver 

All the batch files listed in this section may be found on the Sample Code 
Disk. 



5.3.1 RIPL Server Preparation 

1. Install IBM OS/2 LAN Server V2.0 on the machine which is to be the server. 
Install the OS/2 Remote IPL support on this machine. Ensure that the drive 
on which you install LAN Server will have over 65MB of free space after 
installation of LAN Server, as we still have to install two full copies of OS/2 
V2.0 (one for RIPL and one for RSPINST). 

2. Run the RIPLINST utility of OS/2 V2.0 as detailed in Chapter 4 of IBM 
Operating System/2 Local Area Network Server Version 2.0 Network 
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Administrator Reference Supplement, S04G-1080. Install the OS/2 V2.0 system 
in the \IBMLAN\RPL\OS2.20 directory. 

3. Create the directory \IBMLAN\RPL\0S2INST. This will be the root of the OS/2 
V2.0 diskette images created by the SEIMAGE utility. 

4. Unpack and run the SEIMAGE utility (as described in section 4.1.1, 
“SEIMAGE” on page 18). Specify the target directory as 
\IBMLAN\RPL\OS2INST. The following command will create the SEIMAGE 
directory structure, assuming LAN Server is installed on the C: drive: 

SEIMAGE /S:a: /T:c:\ibtn1an\rp1\os2inst 

5. Start the server, and log on using an administrator ID. For example, if the 
default administrator ID is still valid: 

NET START SRV 

LOGON USERID /P: PASSWORD 

6. If the server automatically started the RemoteBoot service, you should stop 
that service at this point. 

NET STOP RIPL 



7. Run the GETRPL utility as outlined in IBM Operating System/2 Local Area 
Network Server Version 2.0 Network Administrator Reference Volume 3, 
S04G-1034. This procedure will complete the OS/2 V2.0 Remote IPL 
configuration process. 

8. Create a master remote workstation definition. This master definition will be 
used as the model for all client workstation definitions. If you are not familiar 
with how to create Remote IPL workstation definitions through the LAN 
Server full screen interface, refer to Chapter 4 of IBM Operating System/2 
Local Area Network Server Version 2.0 Network Administrator Reference 
Supplement, S04G-1080. 

At the Create a Remote IPL Requester Definition panel, fill in the fields as 
follows: 



Field 



Value (Comments) 



Machine ID 



RIMODEL 



Description 

Network Adapter Number 



Server Record Identifier 



File Index Table to model 



Model Remote Installation Workstation 

Enter a value here that is a dummy 
adapter that does not exist in your 
network, or in any networks connected 
via bridges. If you are using token-ring, 
a suggested value is 10005AFFFFFD. 

Use the F4=List feature to select a 
record of the form R_20_0xx, where xx 
identifies the LAN adapter being used 
(TK, ET, PC, or PCA). For example, if 
you are using token-ring adapters, 
select R_20_0TK. 

DEFALT20.FIT 



9. Edit the file \IBMLAN\RPL\FITS\RIMODEL.FIT. Do a global change of all 
occurrences of “C:” in the file to “Z:.” 



10. Change the line in the \IBMLAN\RPL\FITS\RIMODEL.FIT file that reads: 
Z : \C0NFIG. SYS HACHINES\RIN0DEL\C0NFIG . 20 
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so that it now reads: 

Z:\CONFIG.SYS HACHINES\RIHODEL\CONFIGRI.20 

Note: By default, the CONFIGRI.20 file (which is the CONFIG.SYS seen by 
the RIPL clients) contains the following PROTSHELL: 

PR0TSHELL-Zt\0S2\CMD.EXE /K Z:\0S2\INSTALL\RSPINST , EXE Z:\0S2\INSTALL\INSTALL.RSP 

This will execute the OS/2 V2.0 response file installation program 
RSPINST.EXE, using the response file 
\IBMLAN\RPL\OS2.20\OS2\INSTALL\INSTALLRSP. 

11. (Advanced Scenario only) 

Edit the CONFIGRI.20 to change the PROTSHELL line listed above to: 
PROTSHELL=Z: \0S2INST\DISK_1\SYSINST1.EXE 
Add a line under this line which reads: 

SET 0S2_SHELL=Z» \0S2\CHD.EXE /K Z:\0S2\IHSTALL\RIPLRFI.CMD 

a. Add a RIPLRFI.CMD file to the \IBMLAN\RPL\OS2.20\OS2\INSTALL 
directory: 



9echo off 

detach z:\os2inst\rexinit.exe 
call z:\os2inst\DISKPREP.CMD 
if errorlevel 8 goto skip 

z:\os2\install\rspinst z:\os2\install\install .rsp 
: ski p 



Figure 5. RIPLRFI.CMD 

RIPLRFI.CMD performs the following steps: 

1) Detaches REXINIT.EXE to initialize REXX on the workstation. 

2) Runs DISKPREP.CMD to partition the fixed disk as required. 

3) Skips RSPINST if the user answers “N” to partitioning the disk in 
DISKPREP.CMD. 

4) Executes RSPINST using the response file INSTALL.RSP. 

b. Copy REXINIT.EXE (from the Sample Code Disk) to 
\IBMLAN\RPL\OS2INST 

c. Copy DISKPREP.CMD (from the Sample Code Disk) to 
\IBMLAN\RPL\OS2INST 

d. Copy PIPE.CMD (from the Sample Code Disk) to \IBMLAN\RPL\OS2INST 

e. Create an FDSK.DAT file (as described in Appendix F, “Automating Fixed 
Disk Partitioning" on page 159) in \IBMLAN\RPL\OS2INST. This file 
contains the FDISK commands to partition the fixed disk as you require. 

12. (Advanced Scenario only) 

Edit the CONFIGRI.20 to move Z:\ to the front of Z:\OS2\INSTALL in the 
DPATH. You need only do this if individual response files per workstation 
are required. 
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I Note! 

If individual response files for workstations or partitioning of client fixed 
disks is required (as described in section 5.4, “Advanced RIPL Installation 
Scenario” on page 31), you should edit the CONFIGRI.20 file now, before 
individual workstation definitions are created. If you do not do so, you will 
have to edit each CONFIGRI.20 file in every client directory. See section 
5.4.1, “Advanced RIPL Server Preparation” on page 31 for more details. 

13. Create a response file \IBMLAN\RPL\OS2.20\OS2\INSTALL\INSTALL.RSP to 
provide the keywords required for client installation. Please read 
Appendix A, “Response File Keyword Reference, Samples And Details” on 
page 117 for detailed information on response file keywords. 

14. Using the IBM OS/2 LAN Server V2.0 Full Screen Interface, create remote IPL 
workstation definitions for the workstations that are to be installed. Make 
sure you use the modelling feature of the “Create Remote IPL Requester 
Definition” function, using RIMODEL as the model for each workstation. 

15. Edit the IBMLAN\RPL\RPL.MAP file. Update field 6 in each workstation 
record from a to a “Z.” This specifies that the workstation will use a 
boot drive of Z:. For example, if the line in RPL.MAP was: 

18B05A219C3D HORSE ' FITS\HORSE AWRPLSRV " R_28_0TK 

you should change it to: 

16005A219C3D HORSE " FITS\HORSE AWRPLSRV Z ' R_28_0TK 

16. Start the RemoteBoot service: 

NET START RIPL 




Figure 6. Mapping of RIPL Drives and Directories 
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5.3.2 Preparation of the RIPL Installation Diskette 



5.3.2.1 Token-Ring, Using RPLDISK Utility 

The following procedure is used to create a token-ring RIPL Installation diskette. 
This diskette will be used to replace the token-ring adapter RIPL ROM module, 
and will be used by the “installers” to initiate installation on the clients. 

1. Use the DOS FORMAT command to create a DOS system diskette. 

FORMAT A: /S 

The (/S) parameter specifies add DOS system files and create a DOS 
bootable system diskette. 

2. Use the DOS or OS/2 ATTRIB command to clear the DOS system files 
attributes on the DOS system diskette. 

ATTRIB -r -s -h A:\IBMBI0.C0M 
ATTRIB -r -s -h A:\IBMD0S.C0M 

3. Copy the RPLDISK.EXE program from the \IBMLAN\NETPROG directory of 
your server to the DOS system diskette. For example, if LAN Server is 
installed on the C: drive: 

COPY C:\IBMLAN\NETPROG\RPLDISK.EXE A:\ 

4. Run the RPLDISK program to replace DOS system files and create a 
token-ring RIPL bootable diskette. 

A:\RPLDISK A: -o 

The (A:) parameter specifies replace the files on the A: drive. 

The (-o) parameter specifies overlay existing system files. 

Both parameters are required for the RPLDISK DOS system file replacement 
program to execute correctly. 

5. Use the DOS or OS/2 ATTRIB command to reset the DOS system files 
attributes on the DOS system diskette. 

ATTRIB +r +s +h A:\IBMBI0.C0M 
ATTRIB +r +s +h A:\IBHD0S.C0M 

6. The RIPL Installation Diskette is now ready for use. 

Note: There are possible conflict problems with the RPLDISK utility and the 386 
Enhanced Memory Option Adapter. If you are using this adapter on your client 
and have less than 6MB of planar memory, the EMO memory may not be seen 
by the client, and installation could fail. 

A device driver DOSMEMDD.SYS is provided on the Options Diskette of the 
memory adapter. Add this driver to your RIPL Installation diskette, and a 
DEVICE = DOSMEMDD.SYS statement in a CONFIG.SYS on the diskette, if your 
clients use this hardware. 

5.3.2.2 Non Token-Ring, Using RPLENABL Utility 

In this case the RIPL Installation diskette is the diskette that the “installers” will 
use to disable the fixed disk of the clients so that they will RIPL from the server 
and install. The following steps will create the diskette: 

1. Create a DOS bootable diskette. 

2. Copy the RPLENABL.EXE onto the diskette from the \IBMLAN\RPL\DOS 
directory of the server. 
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3. Add an AUTOEXEC.BAT to the diskette: 



@echo off 

echo =============================== 

echo Enabling RIPL, please wait, 
echo ======= = == = = =====— "== === ===== 

rplenabl 

echo 

echo Remove the Installation diskette 
echo from the diskette drive and 
echo reboot (Ctrl - Alt - Del) 
echo ================================ 

pause > nul 
:loop 
goto loop 

Figure 7. RIPL Installation AUTOEXEC.BAT 

I Ready to install! (Basic Scenario) 

★ ★ ★ ★ ★ 

When the “installer” boots from the Installation diskette, the client will be 
installed as a fully functional OS/2 V2.0 workstation. 



5.4 Advanced RIPL Installation Scenario 

The previous example works well for a simple setup where all workstations can 
use the same response file, and installation logs are not collected at a central 
point. In this section we will provide an example allowing for individual response 
files and centralized installation information. 

This section will also describe automating fixed disk partitioning, using the REXX 
procedures from Appendix F, “Automating Fixed Disk Partitioning” on page 159. 

5.4.1 Advanced RIPL Server Preparation 

Set up the RIPL Server exactly as described in section 5.3.1, “RIPL Server 
Preparation” on page 26. Make sure you perform the steps marked “(Advanced 
Scenario only)” as well. 

Now perform these extra steps: 

1. Update the \IBMLAN\RPL\OS2.20\OS2\INSTALL\INSTALLRSP response file 
to include the following statements: 

Include=indiv.rsp 

UserExi t=Z : \0S2\IMSTALL\P0STIWST . CMC 

Refer to Appendix A, "Response File Keyword Reference, Samples And 
Details” on page 117 for detailed descriptions of the response file keywords 
Include and UserExit. 

2. Place a dummy INDIV.RSP file in the \IBMLAN\RPL\OS2.20\OS2\INSTALL 
directory. This will be seen as Z:\OS2\INSTALL\INDIV.RSP by the clients. 



Chapter 5. IBM LAN Client/Server Solution 31 




* Dummy response file for workstations which do not have 

* a specific one 

ConfigSysLine=REM This workstation used the dummy INDIV.RSP 
Figure 8. Sample Dummy INDIV.RSP ~ 

3. For each workstation that requires an individual response file, place an 
INDIV.RSP file in the IBMLAN\RPLUSERV‘client name” directory, where 
“client name” is the workstation name. For example, if a workstation 
definition for a machine called HORSE had been created, place the 
INDIV.RSP file for that workstation in the \IBMLAN\RPLUSER\HORSE 
subdirectory. 

The DEFALT20.FIT file is designed so that unresolved references to files will 
go to the root of the \IBMLAN\RPLUSER\“client name” directory of the 
server. The lines in the HORSE.FIT file are: 

; Other references go to the per-workstation root. 

Zi\ \\AWRPLSRV\WRKFILES\HORSE 

The netname \\AWRPLSRV\WRKFILES (which is automatically created by 
IBM OS/2 LAN Server V2.0 when the Remote IPL Workstation Definition is 
created) corresponds to the directory \IBMLAN\RPLUSER on the server 
AWRPLSRV. What this line from the FIT file means is that references from 
the client system HORSE to a file Z:\INDIV.RSP, will be resolved to the file 
\IBMLAN\RPLUSER\HORSE\INDIV.RSP on the RIPL server AWRPLSRV. 

Since Z:\ has been added to the front of the DPATH in the CONFIGRI.20 file, 
all workstations will first search their individual directory for data files. 

Since the response file installation process searches along the DPATH for 
response files, if an INDIV.RSP file exists in the workstation directory it will 
be found first and interpreted. 

If no such file exists, the dummy INDIV.RSP file will be found, since 
Z:\OS2\INSTALL is also in the DPATH (corresponding to 
\IBMLAN\RPL\OS2.20\OS2\INSTALL\INDIV.RSP on the server). 

4. Place a POSTINST.CMD command file in the 

\IBMLAN\RPL\OS2.20\OS2\INSTALL directory. This file will copy the 
installation log INSTALL.LOG to the \IBMLAN\RPLUSER\“client name” 
directory of the server. 



copy c:\os2\install\install.log z:\install.log 
Figure 9. Sample POSTINST.CMD 

Note: This file can easily be expanded to copy other files or applications 
from server to client, as part of the installation process. It could also be used 
to run the RINSTPRN program (included in Appendix H, “Source Code for 
Remote Printer Installation Program” on page 177) for multiple printer 
installation. 

5. Make sure you have placed the RIPLRFI.CMD file in the 

\IBMLAN\RPL\OS2.20\OS2\INSTALL directory, and updated the CONFIGRI.20 
file on the server, as described in the “(Advanced Scenario only)” steps in 
section 5.3.1, “RIPL Server Preparation” on page 26. 
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I Ready to install! (Advanced Scenario) 

★ ★ ★ ★ ★ 

When the “installer” boots from the Installation diskette, the client will be 
partitioned. The “installer” must then reinsert the Installation diskette and 
boot to Remote IPL again. The installation process then completes, leaving 
the client as a fully functional OS/2 V2.0 workstation. 
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Chapter 6. TCP/IP Client/Server Solution 



This chapter describes a method of obtaining a redirected drive letter for OS/2 
V2.0 installation using the Network File System** (NFS**) feature of IBM TCP/IP 
for OS/2. Use of this facility allows a workstation to be installed from any system 
that provides NFS server capability. Examples of such systems include: 

• OS/2 Systems (TCP/IP for OS/2 + NFS feature) 

• AIX Systems (IBM RS/6000) 

• ONIX Systems which support an NFS Server capability 

• VM Systems (TCP/IP for VM) 

• MVS Systems (TCP/IP for MVS). 

This chapter is organized into several sections: 

• 6.1, “Overview of the Network File System” introduces the NFS capability of 
TCP/IP. 

• 6.2, “NFS Installation Scenarios” on page 36 discusses different methods of 
OS/2 V2.0 installation using NFS, and summarizes the steps required to 
complete an installation. 

• 6.3, “Basic NFS Installation Scenario” on page 38 describes a simple 
installation scenario that installs OS/2 V2.0 on the clients, using the response 
file installation method. 

• 6.4, “Advanced NFS Installation Scenario” on page 45 describes a more 
advanced scenario that takes into account a more complex network, use of 
individual customization of clients, and collection of installation logs back to 
a central point. Again, this installation is performed using the response file 
installation method. 

• 6.5, “A Dialog-Driven Installation using TCP/IP and NFS" on page 55 
describes the setup of servers and client diskettes for a redirected I/O 
dialog-driven installation of OS/2 V2.0. 

• 6.6, “Disketteless Upgrade of OS/2 V1.3 TCP/IP Workstations" on page 58 
describes a method of upgrading OS/2 VI. 3 TCP/IP workstations to OS/2 
V2.0, without booting from diskettes. 



6.1 Overview of the Network File System 

NFS allows you to share drive resources across a network. The NFS MOUNT 
command allows you to access a file system on a server from a client and have 
the client view the remote file system as if it were a local drive. Thus the 
command: 

MOUNT Z: NFSSRV:/os2inst/image 

will create a drive Z: on the client corresponding to the /os2inst/image directory 
of the NFS server called “NFSSRV.” NFS MOUNT is analogous to OS/2 LAN 
Server's NET USE. 

IBM implements both NFS client and server function in IBM TCP/IP for OS/2 VI. 2. 
For more information on TCP/IP and NFS for OS/2 V2.0 you should refer to IBM 
Transmission Control Protocol/ Internet Protocol Version 1.2 for OS/2 User' s 
Guide, SC32-6076. For more information on the OS/2 NFS server function, refer to 



© Copyright IBM Corp. 1992 



35 



IBM Transmission Control Protocol/Internet Protocol Version 1.2 for OS/2 
Installation and Maintenance, SC31-6075. 

The obvious application for NFS in our environment is to mount a redirected 
drive containing the OS/2 V2.0 SEIMAGE subdirectories, and perform an 
RSPINST installation from the NFS drive. 



6.2 NFS Installation Scenarios 

The purpose of the redirected I/O and response file capability provided with OS/2 
V2.0 is to simplify the installation of OS/2 V2.0 workstations. Redirected I/O 
removes the need to transport large numbers of diskettes to every workstation. 
Response files allow the administrator to control all facets of a workstation's 
installation without the user answering any questions about the installation. 

Refer to Chapter 2, "Redirected Input/Output and Response Files” on page 3 for 
more information. 

In the following sections techniques are described to allow an administrator to 
use a TCP/IP network as the redirected I/O method. NFS provides the redirected 
drive. 

NFS can be used for OS/2 V2.0 remote installation from a variety of server types. 
A simple solution is to use an OS/2 system as the NFS server since TCP/IP for 
OS/2's NFS feature includes the server function anyway. 

However, if you have an existing TCP/IP network with an NFS server, you can 
use this machine as the distribution platform for OS/2 V2.0 installation. The 
possibilities are detailed below. 

• TCP/IP for OS/2 NFS installation server: 

— Install TCP/IP for OS/2 with NFS server feature. 

— Use SEIMAGE to create the install subdirectory and add this directory to 
the server EXPORTS file as detailed in Chapter 9 of IBM Transmission 
Control Protocol/ Internet Protocol Version 1.2 for OS/2 Installation and 
Maintenance, SC31-6075. 

— Start the NFS server. 

- The clients may now MOUNT the install subdirectories as a Z: drive and 
run RSPINST (refer to 6.3.3, “Preparation of the NFS Client LT Diskette” 
on page 40) or SYSINST2 (refer to 6.5, "A Dialog-Driven Installation using 
TCP/IP and NFS” on page 55). 

A variation on this method is to use the "injection” technique. Set up the 
OS/2 NFS server on a portable system with a LAN adapter. Take that system 
to each site where installation is required and connect to the LAN. All 
workstations can be installed or upgraded and the “injection” system moves 
on to the next site. 

• “Other” NFS installation servers: 

In this situation the server could be an AIX system, or even MVS or VM 
mainframe. NFS server must be installed on the host system. 

— Install TCP/IP for OS/2 with NFS client feature on a workstation which is 
connected to the NFS server. 

- MOUNT the filesystem on the host which is to be used for installation, 
and run SEIMAGE with the mounted drive specified as the target. 
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— The clients may now MOUNT the install subdirectories as a Z: drive and 
run RSPINST (refer to 6.3.3, "Preparation of the NFS Client LT Diskette” 
on page 40) or SYSINST2 (refer to 6.5, “A Dialog-Driven Installation using 
TCP/IP and NFS” on page 55). 

Two scenarios are described in 6.3, “Basic NFS Installation Scenario” on 

page 38 and in 6.4, “Advanced NFS Installation Scenario” on page 45. The 

assumptions made for each scenario are: 

• Basic Scenario 

— The TCP/IP network is a small private network. 

— The server used is an OS/2 NFS server called "nfsserver.” (However, 
where procedures are different for a non-OS/2 server, alternate 
examples have been given for an NFS server called “RS6000.”) 

— The OS/2 V2.0 installation subdirectories will be stored on the 

“nfsserver” system under C:\OS2SE20 (or on the “RS6000” system under 
/image). 

— The administrator has prepared a response file called OS2SE20.RSP, 
which defines the installation parameters for all clients. 

— The fixed disks of all clients are already partitioned as desired. 

• Advanced Scenario 

— The workstation fixed disks will be repartitioned as part of the installation 
process. 

— All workstations are on a complex TCP/IP network. 

— The server used is an OS/2 NFS server called “HORSE.” 

— The OS/2 V2.0 installation subdirectories will be stored on the “HORSE” 
system under D:\IMAGE. 

— The administrator will prepare a common response file OS2SE20.RSP, 
but will also prepare individual response files for each workstation called 
INDIV.RSP. This is explained in detail in 6.4, “Advanced NFS installation 
Scenario” on page 45. 

- The client's installation logs will be collected back to the server so the 
administrator will have a central record of all installations. 

— TCP/IP for OS/2 will be installed on the client as part of the installation. 

6.2.1 Overview of Installation Steps for NFS 

In both scenarios the flow of installation steps is the same: 

1. The administrator prepares the server. 

2. The administrator prepares the client LT diskettes. 

3. The administrator makes as many copies of the LT diskettes as required. 

4. “Installers,” each with a set of LT diskettes, travel to each client. 

5. At a client system, the “installer” inserts DISK_0 and boots the client. 

6. When prompted for Disk 1, the "installer” inserts the LT diskette. 

7. The "installer” answers a prompt to enter the client's network address (and 

workstation name in the advanced scenario). 

8. The client completes OS/2 V2.0 installation. 
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9. The “installer” removes the LT diskette and reboots the client, which is now 
a fully functioning OS/2 V2.0 system. 



6.3 Basic NFS Installation Scenario 

This section describes a scenario that will allow an administrator to quickly set 
up an NFS server, create some LT diskettes, and install OS/2 V2.0 on the clients. 

Time Saver 

All the batch files listed in this section may be found on the Sample Code 
Disk. 



6.3.1 NFS Server Preparation for Basic Scenario 

The preparation required on the server will differ slightly depending on whether 
the server is an OS/2 system or not. 

• OS/2 NFS installation server: 

1. Install TCP/IP for OS/2 VI. 2 on the server. 

2. Install the NFS Server feature. 

3. Using the method described in 4.1.1, “SEIMAGE” on page 18, create the 
OS/2 V2.0 installation subdirectories on the server. 

4. Add the OS/2 V2.0 installation subdirectories to the server's EXPORTS 
file (the EXPORTS file is detailed in Chapter 9 of IBM Transmission 
Control Protocol/Internet Protocol Version 1.2 for OS/2 Installation and 
Maintenance, SC31-6075 ). 




Figure 10. Example TCP/IP for OS/2 NFS Server EXPORTS File. In this example the 
directories listed have been made available to all clients on a read-only basis. The OS/2 
V2.0 installation subdirectories are under C:\OS2SE20. 



5. Copy the RSPINST.EXE program to the root of the SEIMAGE directories. 

6. Create the OS2SE20.RSP response file in the root of the SEIMAGE 
directories. 

7. Start the NFS server. 

• “Other” NFS servers: 

1. Install TCP/IP for OS/2 VI. 2 on an administrator OS/2 workstation which 
has access to the NFS server. 

2. Install the NFS client feature on this workstation. 

3. Export a file area on the NFS server. The administrator should have write 
access to this area, and all clients should have read access. 

4. Start the administrator NFS client. 

5. From this client, MOUNT the exported file area on the NFS server. 
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6. Using the method described in section 4.1.1, “SEIMAGE” on page 18 , 
create the OS/2 V2.0 installation subdirectories on the mounted drive on 
the server. 



MOUNT z: RS60OO: /image 
SEIMAGE /S:a: /T:z:\ 



Figure 11. Example Commands to Set up Non-OS/2 NFS Server. In this example we 
show the sequence of commands to set up a directory called "/image" on an NFS server 
called "RS6000." 

7. Copy the RSPINST.EXE program to the root of the SEIMAGE directories. 

8. Create the OS2SE20.RSP response file in the root of the SEIMAGE 
directories. 

— Extended Attributes 

During the SEIMAGE process you will receive error messages reporting 
that Extended Attributes (EAs) have been lost, if the target file system 
does not support EAs. This will not cause problems with installations 
except for certain printer drivers. See 6.3.2, “Extended Attributes (EA) 
Considerations" on page 40 for more information. 



NFS Server 




Figure 12. Example of TCP/IP NFS Client Installation 
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6.3.2 Extended Attributes (EA) Considerations 

When using a non-OS/2 NFS server, it is quite likely that the file system of the 
server will not support extended attributes. In this case, all EAs attached to files 
on the OS/2 V2.0 diskettes will be lost as part of the SEIMAGE process, so that 
the files on the NFS server will be without EAs. 

The OS/2 V2.0 installation programs have been written to take into consideration 
file systems that do not support EAs (CD-ROM, for example, does not support 
them). You may notice in the PMDD subdirectories there are several *.EA files. 
These contain the extended attribute information in a normal file format which 
can be accessed by the installation programs. 

You may still encounter some problems: 

• The *.FNT files from PMDD_1 will not be copied at all to a file system that 
does not support extended attributes. This means if you install a printer that 
requires the LASERJET driver, the *.FNT files will not be present. 

• The RINSTPRN program included in Appendix H, “Source Code for Remote 
Printer Installation Program” on page 177 does not include the capability to 
query the *.EA files if extended attributes are not present in the server files. 
This means that this program will not install printers properly if it uses a 
non-OS/2 NFS server as the source drive. It will seem to complete 
successfully but not all drivers and DLLs will be copied to the client. 

Solving EA difficulties 

If you have to install the LASERJET driver, or want to use the RINSTPRN 
program to install more than one printer, and you have a server that does 
not support EAs, use the following technique: 

1. “Pack” the PMDD directories into a single file on the OS/2 administrator 
workstation. You must use a utility that supports extended attributes. The 
PACK.EXE from the OS/2 V2.0 Programming Toolkit is recommended. 

2. Specify NO default printer in the RSPINST response file. 

3. Create a command file that will perform the following steps: 

a. Copy the “packed” files from the server to the client, and unpack the 
files into PMDD directories on the local fixed disk. 

b. Run RINSTPRN, using the directories on the client local fixed disk. 

c. At the completion of RINSTPRN, delete the PMDD directories from the 
client. 

4. Set up your response file with a UserExit keyword that will run the 
command file you created above. See Appendix A, “Response File 
Keyword Reference, Samples And Details" on page 117 fora detailed 
description of the UserExit keyword. 



6.3.3 Preparation of the NFS Client LT Diskette 

Once an NFS server with SEIMAGE directories is set up on the network the 
administrator must create the Client Install diskettes using the SEDISK utility 
(see 4.1.2, “SEDISK” on page 19). If your NFS server is not an OS/2 system, you 
must MOUNT the SEIMAGE directories from an OS/2 client and run SEDISK from 
the OS/2 client. 
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MOUNT z: RS6000: /image 
SEDISK /S:z:\ /T:a: 



Figure 13. Example Commands to Create SEDISK Diskettes for OS/2 V2.0 

If your NFS server is an OS/2 system, then you may just run SEDISK locally on 
that system. 

The second disk produced by SEDISK must now have LAN Transport drivers and 
TCP/IP files added, and the CONFIG.SYS on this diskette must be updated. To 
achieve this, start at a workstation that has TCP/IP for OS/2 and NFS Client 
installed. Place the second SEDISK diskette in the diskette drive, and perform 
the following commands: 

• If your client systems are non-Micro Channel systems: 

ERASE A:\*02.SYS 

• If your client systems are Micro Channel systems: 

ERASE A:\*ei.SYS 

This will clear some space on the diskette which is required to fit all the TCP/IP 
files. 

Now copy all the TCP/IP files onto the diskette. Figure 14 shows the commands 
to execute. 

Note: This example assumes TCP/IP and LAPS are installed on the C: drive of 
the workstation. The workstation has a token-ring adapter (and so uses 
1BMTOK.OS2). You must copy a different driver if your workstations use different 
adapters (refer to the LAPS documentation of TCP/IP for OS/2). 



COPY C:\IBMCOM\DLL\LANMSGDL.DLL A:\ 
COPY C:\IBMCOM\LANMSGDD.OS2 A:\ 

COPY C:\IBMCOM\LANMSGEX.EXE A:\ 

COPY C:\IBMC0M\PR0TMAN.0S2 A:\ 

COPY C:\IBMC0M\PR0T0C0L.INI A:\ 

COPY C:\IBMCOM\NETBIND.EXE A:\ 

COPY C:\IBMC0M\PR0.MSG A:\ 

COPY C:\IBMC0M\LT2.MSG A:\ 

COPY C:\IBMCOM\LT0.MSG A:\ 

COPY C:\IBMC0M\MACS\IBMT0K.0S2 A:\ 
COPY C:\TCPIP\BIN\CNTRL.EXE A:\ 

COPY C:\TCPIP\BIN\NFS.IFS A:\ 

COPY C:\TCPIP\BIN\IFNDIS.SYS A:\ 
COPY C:\TCPIP\BIN\IFCONFIG.EXE A:\ 
COPY C:\TCPIP\BIN\INET.SYS A:\ 

COPY C:\TCPIP\BIN\ARP.EXE A:\ 

COPY C:\TCPIP\BIN\MOUNT.EXE A:\ 

COPY C:\TCPIP\BIN\NFSCTL.EXE A:\ 
COPY C:\TCPIP\BIN\NFSBIOD.EXE A;\ 
COPY C:\TCPIP\DLL\TCPIPDLL.DLL A:\ 
COPY C:\TCPIP\DLL\RPCDLL.DLL A:\ 

MO A:\ETC 



Figure 14. Commands to Update Second SEDISK Diskette for NFS 
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The next step is to create a HOSTS file and copy it to the A:\ETC subdirectory. A 
HOSTS file is a fiat ASCII file that allows a workstation to resolve references to 
server aliases into complete network addresses. See Chapter 1 of IBM 
Transmission Control Protocol/Internet Protocol Version 1.2 for OS/2 User's 
Guide, SC32-6076 , for more information on the TCP/IP HOSTS file. 

A sample HOSTS file, shown below, defines the system with address 128.0.100.3 
to be known as “nfsserver” from this client. 



128.0.100.3 nfsserver 



Figure 15. Example HOSTS File 

The next step is to update the CONFIG.SYS on the diskette. An example 
CONFIG.SYS is shown below. Lines that have been modified or added to the 
original SEDISK CONFIG.SYS are shown in capital letters. 
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buffers=32 

i opl =yes 

memman=noswap 

protshen=sysi nstl.exe 

SET 0S2_SHELL=CMD . EXE /K NFSRFI.CMD 

diskcache=64,LW 

protecton1y=yes 

1 i bpath=. ;\;\os2\dl 1 ; 

ifs=hpfs.ifs /c:64 

pauseonerror=no 

codepage=850 

devi nf o=kbd , us , keyboard . dcp 
devinfo=scr,ega,vtbl850.dcp 
device=\dos.sys 
device=\mouse.sys 

SET PATH=\ ;\0S2; \0S2\SYSTEH; \0S2\ INSTALL 5 Z : \DISK_1; 

set dpath=\;\os2;\os2\system;\os2\i nstal 1 

set keys=on 

basedev=print01.sys 

basedev=i bmlfl py.add 

basedev=i bmls506. add 

basedev=i bm2fl py.add 

basedev=ibm2adsk.add 

basedev=ibm2scsi .add 

basedev=i bmi nt 13. i 13 

basedev=os2dasd . dmd 

devi ce=\testcfg . sys 

SET SOURCEPATH=Z:\ 

DEVICE=\LANHSGDD.0S2 /I:A:\ 

RUNo\UNNSGEX.EXE 

DEVI CE=\ PROTHAN . 0S2 /I:A:\ 

DEVICE°\IBHTOK. 0S2 

DEVICE=\INET.SYS 

DEVICE=\IFNDIS.SYS 

RUN-\NETBIND.EXE 

SET ETC=A:\ETC 

SET THP=A:\ETC 

TIHESLICE=160, 100 

RUN-\CNTRL.EXE 

IFS=\NFS.IFS 

SET HOSTNAHE^NFSREQ 

Figure 16 . Example CONFIG.SYS for NFS LT Diskette 

Now you need to add CRENVVAR.EXE (see Appendix I, “The Create Environment 
Variable Program Description" on page 213), and NFSRFI.CMD to this diskette. 
NFSRFI.CMD is a batch file to do an NFS redirected, response file installation. 
NFSRFI.CMD uses CRENVVAR to prompt the user for an IP address for the 
workstation. 

CRENVVAR creates an ENV_VAR.CMD file, which is then executed by 
NFSRFI.CMD. 

NFSRFI.CMD then starts the required TCP/IP functions, MOUNTS the Z: drive {the 
SEIMAGE directories), and starts RSPINST.EXE. 
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Below is a simple NFSRFI.CMD file. See 6.4, “Advanced NFS Installation 
Scenario” on page 45 for a more sophisticated installation setup that allows 
individual response files on each workstation, and copies each workstation's 
INSTALL.LOG back to the server. 

BOOTP Protocol 

You may use the BOOTP Bootstrap Protocol of TCP/IP to allow workstations 
to set their IP address from the server rather than have the user enter an 
address. See Chapter 13 of IBM Transmission Control Protocol/Internet 
Protocol Version 1.2 for OS/2 User's Guide, SC32-6076, for more information 
on BOOTP. In this publication we have not used BOOTP. 



Pecho off 

crenvvar /v:addr /p: “Enter your Network Address" 
call env_vars 
arp -f 

ifconfig lanO %addr% 
detach nfsctl.exe 

mount -u -g z: nfsserver:c:\os2se20 
z:\rspinst z:\os2se20.rsp 



Figure 17. Basic NFSRFI.CMD File 

Note: If you are using the non-OS/2 NFS server, then change the MOUNT line in 
Figure 17 to: 

mount z: RS60B0: /Image 

If you do not wish the user to be prompted for logon ID and password, you can 
change the line to: 

mount -lawalte -psharon z: RS6680:/image 

where in this example the ID used is “awaite” with password “sharon.” 

Refer to the chapter on NFS Client in IBM Transmission Control Protocol/Internet 
Protocol Version 1.2 for OS/2 User's Guide, SC32-6076, to check the parameters 
accepted on the MOUNT command by different NFS server systems. 

The following assumptions were made in order for the above example to work 
properly: 

• The SEIMAGE directories are under “C:\OS2SE20” on the NFS server 
“nfsserver.” 

• The access for the C:\OS2SE20 directory on the server is available to 
“everyone.” 

• The files RSPINST.EXE and OS2SE20.RSP have been placed at the root of the 
SEIMAGE directories on the server (Z:\ to the clients, C:\OS2SE20 on the 
server). 

• All clients are using the same response file (OS2SE20.RSP). 
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— Ready to install! (Basic Scenario) 

★ ★ ★ ★ ★ 

When the “installer” boots from the SEDISK DISK_0 and LT diskette, after a 
prompt the client will be installed as a fully functional OS/2 V2.0 workstation. 



6.4 Advanced NFS Installation Scenario 

The previous example works well for a simple setup where all workstations can 
use the same response file, and installation logs are not collected at a central 
point. In this section we will provide an example allowing for individual response 
files and centralized installation information. 

This example assumes an OS/2 NFS server called “HORSE” will be used. 

In this scenario the user is prompted for a workstation name as well as an 
address. On the NFS server the administrator has set up a CLIENTS directory 
that has a subdirectory under it for each workstation name. This directory will 
hold the individual response file for that workstation, and at the completion of the 
installation the workstation's INSTALL.LOG will be copied into this directory. 

Refer to A.6.1, “Single Include File Sample" on page 133 for a detailed 
explanation of individual response files. 

This installation procedure will also install TCP/IP for OS/2 on the client, and 
update all required files on the client fixed disk. 

Thus at the conclusion of the installation procedure the client will be a fully 
functional TCP/IP for OS/2 workstation. 

Time Saver 

All the batch files listed in this section may be found on the Sample Code 
Disk. 



6.4.1 Changes from the Basic Scenario 

The setup of server and client is very simitar to the procedures outlined in the 
previous sections {6.3.1, “NFS Server Preparation for Basic Scenario” on 
page 38 and 6.3.3, “Preparation of the NFS Client LT Diskette” on page 40). The 
variations will be noted here. 

6.4.1 .1 Complex Network 

The previous section assumed that installation was taking place on a small 
private TCP/IP network. In this example we assume that the network includes 
domains, nameservers, and so forth. 

The main change this involves is the addition of a RESOLV file to the A:\ETC 
subdirectory of the Client LT diskette. 
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domain bocaraton.ibm.com 
nameserver 9.83.124.1 



Figure 18. Example RESOLV File 



6.4.1 .2 Use of REXX 

Since this installation uses REXX procedures as a UserExit in RSPINST it is 
required that the clients have access to the OS/2 V2.0 REXX DLLs and message 
files. We assume that these files will be placed on the C: drive of the server in 
this example. To achieve this set up a C:\REXX directory on the server, which 
will contain the files required by OS/2 V2.0 REXX. The following example will 
copy the required files from workstation that has REXX installed on the C: drive. 

COPY C:\0S2\DLL\REX* . DLL C:\REXX 
COPY C : \0S2\SYSTEH\REX* . MSG C:\REXX 

The NFSRFI.CMD on the client LT diskette will do an extra MOUNT to connect to 
the REXX files, and the CONFIG.SYS will have LIBPATH and DPATH updated to 
include this drive (see Figure 24 on page 52 and Figure 23 on page 51). 

In order to initialize REXX on the client, a special program is required - 
REXINIT.EXE. This program is included on the Sample Code Disk. Copy this file 
to the C:\REXX directory as well. 

6.4.1 .3 Client Fixed Disk Partitioning 

The client fixed disks will be partitioned using the DISKPREP.CMD REXX 
program listed in Appendix F, “Automating Fixed Disk Partitioning” on page 159. 
This requires that the files DISKPREP.CMD, PIPE.CMD, and FDSK.DAT are placed 
on the server in the root of the SEIMAGE directories. 

6.4.1 .4 NFSRFI.CMD 

The NFSRFI.CMD (which is run as part of the OS2_SHELL statement in the 
CONFIG.SYS of the client LT diskette) is changed in a few ways. 

• The user is also prompted for a workstation name to which the TCP/IP 
environment variable HOSTNAME is set. 

• The D:\CLIENTS\%hostname% directory is added to the front of the DPATH 
(so that the workstation's INDIV.RSP file will be found). 

• Attempts to create a D:\CLIENTS\%hostname% directory on the server. If 
one exists execution continues anyway. 

• Checks for the existence of a D:\CLIENTS\%hostname%\INDIV.RSP file. If 
none exists a dummy one is copied into the directory. 

• Executes DISKPREP.CMD and skips the installation step if the user answers 
“N" to partitioning the fixed disk. 

• Executes RSPINST using OS2SE20.RSP as the response file. This response 
file now incudes an “Include = INDIV.RSP” keyword. 
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6.4.1 .5 TCPINST.CMD 

The common response file OS2SE20.RSP now calls Z:\TCPINST.CMD as a 
UserExit. This is a REXX program that performs the following functions: 

• Copies the client installation log to the D:\CLIENTS\%hostname% directory. 

• Copies the TCP/IP code to the workstation. 

• Updates the workstation's CONFIG.SYS to include the TCP/IP support. 

The aim of TCPINST.CMD is to have a fully functioning TCP/IP workstation at the 
end of the installation process. 




CLIENT (9.83.124.105) 

HOSTNAM E=pony 



MOUNT X: horse:C:\REXX^ 
MOUNT Z: horse: D:\IMAGE ^ 
MOUNT Y: horse: D:\CLIENTS 



CONFIG.SYS 

libpath-.;\;\os2\dil;x:\; 

setdpath=...;x:V 

set source pa th=z:\ 



NFSRFI.CMD 

CRENWAR N hostname 

/p "Eruer your workstation name" 

SET DPATH=Y Wohostnam e% ,%dpath% 
Z\RSPINST EXE Z VOS2SE20 RSP 



Figure 19. Advanced NFS Installation Setup 



6.4.2 Advanced NFS Server Preparation 

Set up the server as described in 6.3.1, “NFS Server Preparation for Basic 
Scenario” on page 38, with the following additions: 

• Add an entry to the server EXPORTS for the REXX files (as in 6.4.1. 2, “Use of 
REXX” on page 46). 

• Update the OS2SE20.RSP file on the server to add the following lines: 

Include=INDIV.RSP 

UserExit=Z:\TCPINST.CMD 

• Place a dummy DUMMY. RSP file in the root of the SEIMAGE directories (Z:\ 
to the clients). This file will be copied to the 

\CLIENTS\%hostname%\INDIV.RSP file if the administrator has not placed a 
specific INDIV.RSP file there. 
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* Dummy response file for workstations which do not have 

* a specific one 

ConfigSysLine=REM This workstation used the dummy INDIV.RSP 



Figure 20. Sample DUMMY.RSP 

• Make a directory TCPIP and a directory IBMCOM in the root of the SEIMAGE 
directories. From a fully installed OS/2 V2.0 TCP/IP administrator client 
execute the following commands: 



MOUNT z: HORSE:D:\image 

XCOPY C:\TCPIP\*.* Z:\TCPIP /s /e 

XCOPY C:\IBMC0M\*.* Z:\IBMC0M /s /e 



Figure 21. Example Commands to Create TCPIP Directory 

• Modify the Z:\TCPIP\BIN\SETUP.CMD file on the server to remove the 
specific address and add the environment variable %addr%. For example, if 
the line in the SETUP.CMD was: 

ifconfig lanS 9.83. 124. 105 netmask 255. 255. 224.8 
then you should change it to: 
ifconfig lanO %addr% netmask 255.255.224.8 

This will allow us to use the same SETUP.CMD for all clients and use an 
environment variable (which will be set in the client's CONFIG.SYS) for the 
address. 

• Create a CLIENTS directory on the server and add an entry to the server 
EXPORTS file for it. All clients must have write access to this directory. 

• Create a directory under the CLIENTS directory for each client name that will 
have an individualized response file. The directory name should be the same 
as the text that the user will enter when prompted “Enter your Workstation 
Name” by the CRENVVAR program on the client LT diskette. This will also be 
the TCP/IP “HOSTNAME” environment variable. 

You need not create a directory for a workstation if you want it to use only 
the standard OS2SE20.RSP without any additions. 

• Place the required INDIV.RSP response file in the subdirectory for each client 
that will use it. If you do not create an INDIV.RSP file then the DUMMY.RSP 
will be used. 

• Make sure you have read 6.3.2, “Extended Attributes <EA) Considerations" on 
page 40 if you are using non-OS/2 NFS servers. Set up any required 
command files for printer installation, as outlined in that section. 

• Place an OS/2 V2.0 XCOPY.EXE in the root of the SEIMAGE directories on the 
server. The TCPINST.CMD file requires XCOPY.EXE. 

• Copy the files DISKPREP.CMD, PIPE.CMD, and FDSK.DAT to the root of the 
SEIMAGE directories on the server. These are for the fixed disk partitioning, 
and are described in detail in Appendix F, “Automating Fixed Disk 
Partitioning” on page 159. 

• Place the TCPINST.CMD REXX program in the root of the SEIMAGE 
directories on the server. A sample TCPINST.CMD is included below. 
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/* REXX program which will perform the following steps - */ 

/* V 

/* 1. Copy the INSTALL.LOG from the client to the perclient directory */ 

/* on the server. */ 

/* 2. XCOPY the TCPIP and IBMCOM directories from the server to the */ 

/* client. */ 

/* 3. Update existing lines (PATH, LIBPATH, etc. ) in the client */ 

/* CONFIG.SYS as required. V 

/* 4. Add new lines to the client CONFIG.SYS (LAN drivers, etc.) as */ 

/* well as environment variable set statements */ 

I* */ 

/* This program is designed to be run as a UserExit from an RSPINST. */ 

/* It assumes the LTS diskette will be left in the drive until the */ 

/* end of the RSPINST (in order to copy ENV VARS.CMD) */ 

/* ’ V 

address cmd 
'@echo off' 

env= ’ 0S2ENVIR0NMENT ' /* get 0S2 environment */ 

hname-value( 'hostname' , ,env) /* get 3shostname% V 

addr=value('addr ' , ,env) /* get %addr% */ 

/* Get CltDrv from the %targetdrive% environment var */ 

/* This is valid during RSPINST if V 

/* ProcessEnvironment=l. */ 

CltDrv-value('targetdrive' , ,env) 

/* You could also set a TCPDrv variable if you wanted */ 

/* TCP/IP on a separate drive */ 



/* copy the install log */ 

'copy 1 Cl tDrv '\os2\1nstal 1 \i nstal 1 . 1 og yA'hname'Vinstall .log' 

/* copy the TCPIP files */ 

'md 'CltDrv ' \tcpip ' 

'z:\xcopy z:\tcpip\*.* 1 Cl tDrv ‘\tcpip /s /e‘ 

'md 'CltDrv'Xibmcom' 

'z:\xcopy z:\ibmcom\*.* 'CltDrv'Xibmcom /s /e' 

/* Change the PATH, LIBPATH, etc of CONFIG.SYS */ 
oldcs=CltDrv| | '\config.sys' 
newcs^CltDrvj | '\config.new' 

do while lines(oldcs) /* do until end of file */ 

1 ine s l inein(oldcs) /* read a line */ 

line=translate(line) /* put it all upper case */ 

if pos( 'LIBPATH', line) ° 0 then /* if we're on the LIBPATH line */ 
do 

1 ine=l i ne | |CltDrv| | '\TCPIP\DLL; ' | |CltDrv| | ' \IBMC0M\0LL; ' 
end 

if pos ( ' SET PATH', line) <> G then /* if we're on the PATH line */ 
do 

1 ine=l ine| | ' ; ' | |CltDrv| | '\TCPIP\BIN; ' 
end 

if pos ('SET DPATH' ,line) <> 0 then /* if we're on the DPATH line */ 
do 

line=line| | '; ' | iCltOrv] | '\ IBMCOM; ' 
end 

if pos('SET HELP', line) o 0 then /* if we're on the HELP line */ 
do 

line=line| |CltDrv | | '\TCPIP\HELPj ' 
end 

call lineout newcs,line /* write line to config.new */ 

end 

Figure 22 (Part 1 of 2), Example TCPINST.CMD UserExit. 
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/* Now add the new lines required to config.new */ 

call lineout newcs, 'DEVICE"' | |CltDrv| | '\IBMC0M\LANHSGDD.0S2 /I: ' | |CltDrv| | '\IBMC0M' 
call lineout newcs, 'RUN=' | |CltDrv| | '\IBMCOM\LANMSGEX.EXE' 

call lineout newcs, 'DEVICE®' | |CltOrv| | '\IBMC0H\PR0THAN.0S2 /l: ' ||CltOrv| | a \IBHC0H' 
/* The following line adds the token ring driver, modify if neccessary */ 
call lineout newcs, *DEVICE=* | |CltDrv | | ' \ IBHCOM\MACS\IBMTOK. 0S2 ’ 
call lineout newcs, 'DEVICE*' | |CltDrv| | ’ \TCPIP\BIM\INET. SYS* 
call lineout newcs, 'DEVICE 3 ' j |C1tDrv| | "\TCPIP\BIN\IFNDIS.SYS ' 
call lineout newcs, 'RUN- 1 | |C1tDrv|| '\IBMCOM\NETBIND. EXE’ 
call lineout newcs, 'SET ETC=‘ I |CltDrv| | '\TCPIP\ETC 
call lineout newcs, 'SET TMP=' | |CltDrv| | '\TCPIP\ETC 
call lineout newcs, 'TIMESIICE°100, 100' 
call lineout newcs, 'RUN=' | |CltDrv| | '\TCPIP\BIN\CNTRL.EXE' 
call lineout newcs, ' IFS=* | |CltDrv| | '\TCPIP\BIN\NFS. IFS' 

/* close the files */ 
call stream oldcs, 'c', 'dose' 
call stream newcs, 'c', 'dose' 

/* add the SET commands, conveniently found in env_vars.cmd */ 

'copy 'newcs'+a:\env_vars.cmd 'newcs 
/* copy the new config.sys into place */ 

'copy 'newcs' 'oldcs 
'erase 'newcs 



Figure 22 (Part 2 of 2). Example TCPINST.CMD UserExit. 



6.4.3 Advanced Client LT Diskette Preparation 

Follow the steps as outlined in 6.3.3, “Preparation of the NFS Client LT Diskette” 
on page 40 with the following modifications: 

• Add a RESOLV file to the A:\ETC subdirectory, if required (see Figure 18 on 
page 46). 

• Modify the CONFIG.SYS on the LT diskette. This will add support for REXX, 
which is required to run TCPINST.CMD. The only changes are to the 

LIB PATH and DPATH. 
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buffers=32 

i opl =yes 

memman=noswap 

protshel 1 =sysi nst 1 . exe 

SET 0S2_SHELL=CMD. EXE /K NFSRFI.CMD 

diskcache=64,LW 

protectonly=yes 

LIBPATH=. ; \ ; \0S2\DLL; X: \ ; 

ifs=hpfs.ifs /c:64 

pauseonerror=no 

codepage=850 

devi nf o=kbd, us , keyboard . dcp 
devinfo=scr,ega,vtbl850.dcp 
device=\dos.sys 
device=\mouse.sys 

SET PATH=\;\0S2;\0S2\SYSTEM;\0S2\INSTALL; Z:\DISK_1; 

SET DPATH=\ ;\0S2; \0S2\SYSTEH; \0S2\INSTALL 5 X: \ ; 

set keys=on 

basedev=pri ntOl.sys 

basedev=ibmlflpy.add 

basedev=i bmls506.add 

basedev=i bm2fl py . add 

basedev=i bm2adsk.add 

basedev=i bm2scsi .add 

basedev=i bmi ntl3. i 13 

basedev=os2dasd . dmd 

devi ce=\testcf g . sys 

SET SOURCEPATH=Z:\ 

DEVICE=\LANMSGDD . 0S2 /I:A:\ 

RUN=\LANMSGEX. EXE 
DEVICE=\PR0TMAN.0S2 /I:A:\ 

DEVICE=\IBMT0K.0S2 
DEVI CE=\INET . SYS 
DEVI CE=\IFNDIS. SYS 
RUN=\NETBINO.EXE 
SET ETC=A:\ETC 
SET TMP=A:\ETC 
TIMESLICE=100,100 
RUN=\CNTRL.EXE 
IFS=\NFS. IFS 

Figure 23. Example CONFIG.SYS for Advanced NFS LT Diskette 

• Modify the NFSRFI.CMD on the diskette so that it will perform the additional 

MOUNT commands and also prompt for the Workstation Name. 

The batch file must now also detach REXINIT.EXE so that the workstation will 

be able to use REXX. 
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Gecho off 

crenvvar /v:addr /p: "Enter your Network Address" /v:hostname /p: "Enter your Workstation Name" 
call env_vars 
arp -f 

Ifconflg lanO %addr% netmask 255.255.224.0 

detach nfsctl.exe 

mount -u -g z: horses d:\image 

mount -u -g y: horse:d:\dients 

mount -u -g x: horse: c:\rexx 

detach x:\rexlnlt.exe 

call Z:\DISKPREP.CHD 

If errorlevel 8 goto skip 

set dpath*y:\%hostname%;%dpath% 

md y:\%hostname% 

If not exist y:\%hostname%\1nd1v.rsp copy z:\dunmy.rsp y:\%hostname%\1ndiv.rsp 
z:\rspinst z:\os2se20.rsp 
: ski p 



Figure 24. Advanced NFSRFI.CMD File 

— Ready to install! (Advanced Scenario) 

★ ★ ★ ★ ★ 

When the “installer” boots from the SEDISK DISK_0 and LT diskette, after two 
prompts the client will be installed as a fully functional OS/2 V2.0 and TCP/IP 
for OS/2 1.2 workstation. 
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Figure 25. Sample Directory Listing of Advanced TCP/IP LT Diskette 



Chapter 6. TCP/IP Client/server Solution 53 





Table 1. Required Files on LT Diskette for Advanced NFS Install. This table 
summarizes the files and directories that should be added to the LT diskette for the 
Advanced NFS scenario. This table applies to token-ring LAN only. 


Operation 


Source 


File / Directory 


Target 


Copy 


Admin 


\IBMCOM\DLL\LANMSGDLDLL 


A:\ 


Copy 


Admin 


\IBMCOM\LANMSGDD.OS2 


A:\ 


Copy 


Admin 


\IBMCOM\LANMSGEX.EXE 


A:\ 


Copy 


Admin 


\IBMCOM\PROTMAN.OS2 


A:\ 


Copy 


Admin 


\IBMCOM\PROTOCOLINI 


A:\ 


Copy 


Admin 


\IBMCOM\NETBIND.EXE 


A:\ 


Copy 


Admin 


\IBMCOM\PRO.MSG 


A:\ 


Copy 


Admin 


\IBMC0M\LT2.MSG 


A:\ 


Copy 


Admin 


\IBMCOM\LTO.MSG 


A:\ 


Copy 


Admin 


\IBMCOM\MACS\IBMTOK.OS2 


A:\ 


Copy 


Admin 


\TCPIP\BIN\CNTRLEXE 


A:\ 


Copy 


Admin 


\TCPIP\BIN\NFS.IFS 


A:\ 


Copy 


Admin 


\TCPIP\BIN\IFNDIS.SYS 


A:\ 


Copy 


Admin 


\TCPIP\BIN\IFCONFIG.EXE 


A:\ 


Copy 


Admin 


\TCPI P\B 1 N\l N ET.SYS 


A:\ 


Copy 


Admin 


\TCPIP\BIN\ARP.EXE 


A:\ 


Copy 


Admin 


\TCPIP\BIN\MOUNT.EXE 


A:\ 


Copy 


Admin 


\TCPI P\BI N\N FSCTL EXE 


A:\ 


Copy 


Admin 


\TCPIP\BIN\NFSBIOD.EXE 


A:\ 


Copy 


Admin 


\TCPIP\DLL\TCPIPDLLDLL 


A:\ 


Copy 


Admin 


\TCPIP\DLL\RPCDLLDLL 


A:\ 


Make Dir 


- 


A:\ETC 




Create 


-- 


HOSTS 


A:\ETC 


Create 


- 


RESOLV 


A:\ETC 


Copy 


Sample 
Code Disk 


CRENWAR.EXE 


A:\ 


Create 


- 


NFSRFI.CMD 


A:\ 


Modify 


~ 


CONFIG.SYS 


A:\ 


Note: In this table “Admin” is the administrator workstation, an OS/2 V2.0 system 
with TCP/IP and NFS installed. 
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Table 2. Required Fifes on Server for Advanced NFS Install. This table summarizes 
the files and directories that should be placed on the server for the Advanced NFS 
scenario . 


Operation 




File / Directory 


Target 


SEIMAGE 


A:\ 


\DISK_nn, \PMDD_nn 


ZA 


Copy 


Admin 


RSPINST.EXE 


Z:\ 


Create 


-- 


OS2SE20.RSP 


Z:\ 


Create 


- 


DUMMY.RSP 


Z:\ 


Create 


- 


INDIV.RSP 


Y:\%client% 


XCopy 


Admin 


YTCPIP Is le 


Z:\ 


Modify 


- 


SETUP.CMD 


Z:\TCPIP\BIN 


XCopy 


Admin 


MBMCOM /s /e 


ZA 


Copy 


Admin 


XCOPY.EXE 


Z:\ 


Create 


- 


TCPINST.CMD 


ZA 


Copy 


Admin 


\OS2\DLL\REXV 


X:\ 


Copy 


Admin 


\OS2\SYSTEM\REXV 


X:\ 


Copy 


Sample 

Code 

Disk 


REXINIT.EXE 


X:\ 


Note: This table assumes the administrator has mounted Z:, Y:, and X: drives on the 
NFS server, as in Figure 24 on page 52. The Y:\%client% directory exists for every 
client, where %client% is the workstation name. 



6.5 A Dialog-Driven Installation using TCP/IP and NFS 

This section will discuss how to set up so that users can perform a dialog-driven 
installation. This means the users will only need the two client LT diskettes, not 
the complete OS/2 V2.0 package. They will still be required to answer all dialogs 
on their workstation related to the installation - response files are not used in 
this case. 

6.5.1 Overview of Dialog-Driven Installation 

The main difference between a response file installation and a dialog-driven 
installation is that dialog-driven installation uses the standard OS/2 V2.0 
installation program SYSINST2.EXE rather than the response file installation 
program RSPINST.EXE. Refer to 4.2.3, “SYSINST2” on page 22 for more 
information on SYSINST2.EXE. 

The other difference in dialog-driven installation is that the system reboots from 
fixed disk after reading the DISK_5 subdirectory. Refer to 8.1, “Attended 
Dialog-Driven Installation” on page 105 for more information. The sequence of 
dialog-driven installation is summarized here: 

1. User inserts OS/2 V2.0 DISK_0 and boots the workstation. 

2. When prompted, user inserts the NFS client LT diskette and presses Enter. 

3. The user is prompted by the CRENVVAR program to enter a workstation 
address. 

4. The client mounts the redirected drive. 
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5. The user is prompted with the initial standard OS/2 V2.0 installation dialogs, 
which are answered. 

6. The install program installs from the redirected drive, until the DISK_5 
subdirectory is reached. At this point there is enough of a system on the 
client fixed disk to support a minimal Presentation Manager environment. 

7. SYSINST2 builds the new CONFIG.SYS on the fixed disk, including any 
statements that were on the CONFIG.SYS of the LT diskette. 

8. SYSINST2 also copies the files from the ROOT directory of the LT diskette to 
the root of the client fixed disk. 

9. The user removes the LT diskette from the drive and reboots the 
workstation. 

10. The workstation begins IPL from the fixed disk. 

11. At this point, all device drivers and RUN= statements that were loaded in 
the LT diskette are reloaded. 

12. The system initializes a special Presentation Manager shell program called 
INSTSHEL.EXE as the PROTSHELL. 

13. The user selects “Select Features and Install.” 

14. The user selects the “Options” menu, and the “Command Prompt” selection. 

15. The user types "CONNECT” (which runs a CONNECT.CMD batch file). This 
reconnects the client to the server with a MOUNT command. 

16. The user answers all of the OS/2 V2.0 installation dialogs. 

17. Installation of the workstation completes from the NFS server. 

6.5.2 NFS Server Preparation for Dialog-Driven Installation 

Server preparation is identical to that outlined in 6.3.1, “NFS Server Preparation 
for Basic Scenario” on page 38, with one exception. 

The RSPINST.EXE must not be present in the root of the SEIMAGE 
subdirectories. If it is present then SYSINST2 will pass control to RSPINST and a 
default response file installation will occur. Remove or rename RSPINST.EXE 
from the server if it is present. 

If you have workstations that will be using a mixture of dialog-driven installation 
and response file installation, create a new subdirectory under the root of the 
SEIMAGE dierctory and place RSPINST there. Don't forget to update the 
RIPLRFI.CMD file to specify the full path to RSPINST.EXE. 

6.5.3 Preparation of the NFS LT Diskette for Dialog-Driven Installation 

Several changes are required to the LT diskette to allow a dialog-driven 
installation rather than a response file installation. Follow these steps: 

1. Create the LT diskette as outlined in 6.3.3, “Preparation of the NFS Client LT 
Diskette" on page 40. 

2. Place the diskette in the drive and perform the following command: 

CORY A:\ETC\*.* A:\ 

The SYSINST2 process will only copy files from the root of A: to the fixed 
disk, so this commands ensures that the ETC files are also copied to the root 
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of the TargetDrive. The CONNECT.CMD (see below) will copy these files from 
the root of the TargetDrive to an ETC subdirectory before TCP/IP is started. 

3. Place a CONNECT.CMD file in the root directory of A: 



rod \etc 

copy \hosts \etc 
copy \resolv \etc 
call env_vars 
arp -f 

ifconfig lanG %addr% 
detach nfsctl.exe 

mount -u -g z: nfsserver: c:\os2se20 
exit 



Figure 26. CONNECT.CMD File 

4. Remove the NFSRFI.CMD from the LT diskette. 

5. Add an NFSPDI.CMD to the LT diskette. 



@echo off 

crenvvar /vraddr /p: "Enter your Network Address" 
call env_vars 
arp -f 

ifconfig lan0 %addr% 
detach nfsctl.exe 

mount -u -g z: nfsserver: c:\os2se20 
z:\disk_l\sysinst2 z:\ 

Figure 27. Basic NFSPDI.CMD File 

6. The final step is to update the CONFIG.SYS on the diskette. Change the line 
that reads: 

SET 0S2_SHELL=CMD.EXE /K NFSRFI.CMD 
so that it now reads: 

SET 0S2_SHELL=CMD.EXE /K NFSPDI.CMD 

— Ready to Install! (Dialog-Driven Installation) 

★ ★ ★ ★ ★ 

Users may now boot from DISK O and the LT diskette and they will run 
through an OS/2 V2.0 dialog-driven installation. Remember that after the first 
reboot, the user must choose “Select Features and Install,” then the “Options 
... Command Prompt” menu, and type CONNECT, or the connection to the 
server will not be re-established and installation will fail. 
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6.6 Disketteless Upgrade of OS/2 VI .3 TCP/IP Workstations 

This section will describe a method of upgrading OS/2 VI. 3 workstations to OS/2 
V2.0 without booting any diskettes. 

The method described here is still a “pull" method. That is, the upgrade is still 
initiated from the workstation by a user running a batch file. 

An administrator could design a “push” system using the REXEC capability of 
TCP/IP for OS/2, and initiate the upgrade batch file from a central system. 
However, REXEC provides only basic access security. The administrator should 
consider carefully before granting the ability for any workstation on the network 
to run a command at any other! This section will not describe an REXEC solution, 
but you may investigate it further yourself if interested in a “push” upgrade 
system. 

Time Saver 1 

All the batch files listed in this section may be found on the Sample Code 
Disk. 



6.6.1 Summary of Disketteless Upgrade Steps for NFS 

1. The administrator prepares the server. 

2. The administrator places the “upgrade” command file (TCPUPG13.CMD) in a 
directory on the server to which all users have access. 

3. A user runs the “upgrade” command file. 

4. The command file creates a seed OS/2 V2.0 system on the client fixed disk, 
and adds TCP/IP and NFS statements to the seed CONFIG.SYS. 

5. The user reboots the client. 

6. The client reboots under OS/2 V2.0 and runs RSPINST. 

7. The user reboots at the end of installation and OS/2 V2.0 is fully installed. 

6.6.2 Server Preparation for NFS Disketteless Upgrade 

Note 

This section assumes the network setup is identical to that described in 6.3, 
“Basic NFS Installation Scenario” on page 38. You should read that section 
before continuing so that you understand the assumptions made for this 
scenario. 



1. Set up the server as described in 6.3.1, “NFS Server Preparation for Basic 
Scenario” on page 38. 

2. Unpack SEMAINT.EXE as described in 4.1.3, “SEMAINT” on page 19 and 
copy the SEMAINT.EXE file to the root of the SEIMAGE directories. 

3. Unpack SEINST.EXE as described in 4.1.4, “SEINST” on page 20 and copy the 
SEINST.EXE file to the root of the SEIMAGE directories. 

4. Place the CRENVVAR.EXE program (from the Sample Code Disk) in the root 
of the SEIMAGE directories. 



58 OS/2 V2.0 Remote Installation 




5. Place a TCUPGRFI.CMD file in the root of the SEIMAGE directories. 



Gecho off 

crenvvar /viaddr /p: "Enter your Network Address" 
call env_vars 
arp -f 

Ifconfig lan0 %addr% 
detach nfsctl.exe 

mount -u -g z: nfsserver:c:\os2se20 
set REMOTE JN$TALL_$TATE»0 

z:\seinst ?B:c: /T:c:\maint /R: z:\os213upg.rsp /S: 2:\ /Ll;C:\inst. log 



Figure 28. TCUPGRFI.CMD File 

6. Copy the IBMCOM directory from the LAPS diskette of TCP/IP for OS/2. If you 
are mounted to the SEIMAGE directories as a Z: drive, insert the LAPS 
diskette in your diskette drive and perform the following commands: 

MD Z:\IBMC0M 

XCOPY A:\IBMC0M\*.* Z:\IBMC0M /s /e 

7. Place the following TCPUPG13.CMD on a drive to which all users have 
access. 
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/* REXX program which will upgrade 1.3 workstations to 2.0 */ 
f* V 

address cmd 
'Oecho off' 

Cl tDrv* 'C: ' /* set client target drive */ 



'mount -u -g z: nfsserver: c:\os2se20* 

/* Create the seed system */ 

’z:\sema1nt /s:z:\ /ts 'CltDrv'Vnalnt /br'CltDrv' /LI; 'Cl tDrv' \ma1nt.log' 

'copy z:\tcupgrf1.cmd 'CltDrv'Vnalnt' 

'copy z:\crenvvar.exe 'CltDrv'Vnaint' 

'md 'C1tDrv'\1bmcom' 

'xcopy z;\1bmcom\*.* 'CltDrv'\1bmcom /s /e' 

/* Change the PATH, LIBPATH, etc of CONFIG.SYS */ 
ol dcs«Cl tDrv | | ' \conf 1 g . sys ' 
newcs-CltDrvj j '\conf1g.new' 

do while llnes(oldcs) /* do until end of file */ 

line-1 Ineln(oldcs) /* read a line */ 

llne-translate(llne) /* put It all upper case V 

If posCPROTSHELLMIne) <> 0 then /* If on the PROTSHELL line */ 
do 

line- 1 PROTSHELL*' | | Cl tDrv | | '\ma1nt\CMD.EXE /K ' | | Cl tDrv | | '\ma1nt\TCUPGRFI.CMD' 
end 

If po$( 'LIBPATH' , line) <> 0 then /* If we're on the LIBPATH line V 
do 

11ne«11ne| |CltDrv| | '\TCPIP\DLL; ’ | |CltDrv| | '\IBMCOM\DLL; ' 
end 

If pos ( ' SET PATH', line) o 0 then /* If we're on the PATH line V 
do 

11ne*11ne| | '; ' | |CltDrv| | '\TCPIP\BIN; • 
end 

If pos('SET DPATH', line) <> 0 then /* If we're on the DPATH line */ 
do 

11ne°11ne| | '; 1 | | Cl tDrv | | ' \IBHC0M; ' 
end 

If pos(’SET HELP', line) o 0 then /* If we're on the HELP line V 
do 

line-line | |CltDrv| | '\TCPIP\HELP; ' 
end 

call lineout newcs,11ne /* write line to conflg.new */ 

end 



Figure 29 (Part 1 of 2). TCPUPG13.CMD File 
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f* Now add the new 
call llneout newcs, 1 
call llneout newcs, 1 
call lineout newcs,' 
/* The following li 
call lineout newcs, ' 
call lineout newcs,' 
call lineout newcs, 1 
call lineout newcs,' 
call lineout newcs,' 
call lineout newcs,' 
call lineout newcs,' 
call lineout newcs,' 
call lineout newcs,' 



lines required to conflg.new */ 

DEVICE**' | |CltDrv| | * \ I BMC0M\ LANMSGDD • 0S2 /Is ' | |CltDrv| | '\IBMC0M' 
RUN**' | |CltDrv| | '\IBMCOM\LANMSGEX.EXE' 

DEVICE**' | iCltDrvI | '\IBMC0M\PR0TMAN.0S2 /I: ' | |CltDrv| | '\IBHC0H' 
ne adds the token ring driver, modify if neccessary */ 

DEVICE**' | |CltDrv| | ' \ I BHCOM\MACS\ IBHTCK. 0S2 ' 

DEVICE**' | |CltDrv| | ' \TCPI P\BIN\ INET, SYS ' 

DEVICE**' | |CltDrv| | '\TCPIP\BIN\IFNDIS.SYS' 

RUN**' | ICltDrvI | '\IBMCOM\NETBIND.EXE' 

SET ETC**' | ICltDrvI | '\TCPIP\ETC 
SET TMP**’ | ICltDrvI | '\TCPIP\ETC 
TIMESLICE-100,100' 

RUN** ' | |CltDrv| | '\TCPIP\BIN\CNTRL EXE' 

IFS** ’ | |CltDrv| | '\TCPIP\BIN\NFS. IFS' 



f* close the files */ 
call stream oldcs, 'c' , 'dose' 
call stream newcs, ' c ' , 'close' 

/* copy the new config.sys into place */ 

'copy 'newcs' 'oldcs 
'erase 'newcs 

/a****************************************************************/ 
/* Subroutine to write banner to screen V 

say '«*[0»7m'; 

do; /* Normal information message */ 

'@cl s ' ; /* Clear the screen */ 

say '<-[8jlH'; /* Hove cursor to line 8 */ 

say ' (?' || 1 eft ( '=' ,76, '*=') || Y; /* Put V 

say ’ ’ll leftC ’,76) || *lh /* message */ 

say ' 'll center(’The upgrade preparation is complete. ’,76) II 
say ’ 'll leftC ',76) || '||'i 

say ’ '|| center(’The System must now be rebooted. ',76) || '|| 

say ' ' || left(' ',76) || MI’S 

say ' '|| center ('Please Shutdown your workstation 

say ' 'll center('from the Desktop Manager menu and reboot. 

say ' 'll leftC '.76) II 1'; /* In a */ 

say ' I' || left('=' ,76, '=’) II '4';/* pretty box */ 



end; 

do forever 



Figure 29 (Part 2 of 2), TCPUPG13.CMD File 



8. Make sure the response file OS213UPG.RSP will not format the partition, and 
is set to migrate configurations and applications. Refer to the descriptions of 
the FormatPartition, MigrateConfigFiles and MigrateApplications keywords in 
Appendix A, “Response File Keyword Reference, Samples And Details” on 
page 117. 

9. Instruct the users to run TCPUPG13.CMD when they wish to upgrade their 
workstations to OS/2 V2.0. 
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Figure 30. Flow of TCP/IP Upgrade Steps 



The flow of steps taken is shown graphically in Figure 30. 

The user has a Y: drive mounted on the server, on which the administrator has 
placed TCPUPG13.CMD. 

1. The user starts TCPUPG13.CMD. 

2. TCPUPG13.CMD mounts a Z: drive to the SEIMAGE directories 

3. TCPUPG13.CMD calls SEMAINT, which builds seed OS/2 V2.0 system on the 
workstation in the C:\MAINT directory. 

4. SEMAINT builds a seed CONFIG.SYS. 

5. TCPUPG13.CMD continues, downloading the IBMCOM directory, 
TCPUPGRFI.CMD and CRENWAR.EXE from the server to the client. These 
will be required by the client later. 

6. TCPUPG13.CMD modifies the seed CONFIG.SYS to add TCP/IP support. 
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7. TCPUPG13.CMD finishes and the user reboots the seed system. 

8. The seed PROTSHELL runs TCPUPGRFI.CMD, which re-mounts the Z: drive 
and calls RSPINST. 

9. Installation of OS/2 V2.0 completes. 

This example could easily be modified to provide a dialog-driven installation 
using the techniques described in 6.5, “A Dialog-Driven Installation using TCP/IP 
and NFS” on page 55. You could also add the advanced features of 6.4, 
"Advanced NFS Installation Scenario” on page 45 if required. 

Note that the migration process will REM all DEVICE, RUN, and IFS statements 
from the OS/2 VI. 3 CONFIG.SYS. The user must manually remove the REM from 
the desired statements, or the administrator could design a REXX procedure to 
automate the task. 



Chapter 6. TCP/IP Client/Server Solution 63 




64 OS/2 V2.0 Remote Installation 




Chapter 7. Novell Netware Client/Server Solution 

This chapter will describe the automated installation of OS/2 V2.0 using a Novell 
Netware Server as the distribution server and a Novell Netware requester as the 
client. 

This chapter is organized into several sections. They are: 

• 7.1, “Overview of Netware Remote Installation” provides a brief description 
of the two types of remote installation, dialog-driven installation and 
response file installation. 

• 7.2, “Netware Assumptions” on page 66 lists all the assumptions made for 
the chapter. 

• 7.3, “Basic Installation Scenario" on page 67 explains a basic installation 
scenario where only OS/2 V2.0 is installed on the client machine. The steps 
include: 

— The server preparation 
— The LT disk preparation 

- The remote installation of OS/2 V2.0 on the client machine. 

Notice 

In a basic installation there is no Novell Netware requester code installed 
on the client machine, only OS/2 V2.0. 

• 7.4, “Advanced OS/2 V2.0 Installation Scenario" on page 83 describes an 
advanced network installation where OS/2 V2.0 as well as the Netware 
requester code are installed and log files are collected. The topics are: 

— The server preparation 

— The LT disk preparation 

- The remote installation of OS/2 V2.0 and Novell Netware requester code 
on the client machine 

- The ability to tailor each client machine uniquely using individual 
response files 

— The collection of installation log records back to the server. 

• 7.5, "Disketteless Upgrade of OS/2 1.3 for Novell workstations” on page 96 
describes the process of upgrading existing OS/2 VI. 3 client machines to 
OS/2 V2.0 including the Netware requester code. The topics are: 

- The assumptions 

— The server preparation 
— Executing the upgrade. 



© Copyright IBM Corp. 1992 
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7.1 Overview of Netware Remote Installation 

There are two fashions in which to remotely install OS/2 V2.0. They are: 

• Using the OS/2 V2.0 Dialog-Driven Installation 

• Using the OS/2 V2.0 Response File Installation. 

A dialog-driven installation installation requires input by the person performing 
the installation where a response file installation is a more automated way to 
install the OS/2 V2.0 Operating System and uses a response file approach to 
configure the client machine. 

The following paragraphs will explain the two options. For more information on 
dialog-driven installation or response file installation please refer to 2.2, 
“Attended Redirected Installation" on page 4. 

• Dialog-driven installation 

The dialog-driven installation requires manual intervention by the person 
installing the OS/2 V2.0 operating system on the client machine. This method 
of installation is very similar to a manual installation method where the user 
is prompted for the diskettes and responds to questions concerning the 
system configuration. In a dialog-driven installation however there is no need 
to insert the diskettes during the install process. The disk images are read 
from the Server so the user only has to answer the configuration questions 
when prompted for them. 

• Response file installation 

The response file installation process uses the concept of a response file 
that contains all the necessary configuration information as input to the 
installation process. There is no user intervention required once the process 
has started. The disk images are read from the server and the response file 
can be either on the LT disk or on the server. 

In either case a portion of the Novell Netware server will need to be set up in 
the same manner. The LT disk will have some minor differences between the 
dialog-driven installation and response file installation scenarios. Both of 
these are covered in detail later in this chapter and require a LAN 
connection to the Novell Netware server. 

Both installation processes use the concept of a redirected drive to gain access 
to the OS/2 V2.0 images that are accessed on a "server” somewhere on the 
network. For more information on redirected drives see Chapter 2, “Redirected 
Input/Output and Response Files” on page 3. 

7.2 Netware Assumptions 

It is assumed that the reader following the procedures in this chapter is familiar 
with Novell Netware, the administrative terms as well as the commands 
associated with it. If this is not the case, it is recommended that a copy of the 
Novell Netware administrator's manual and/or quick reference guide be 
available. 

The server must be a Netware/386 server, otherwise known as Version 3.11 or 
later and installed following the normal Netware server installation procedures. 
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The Novell Netware server must have the OS2 support already installed on it and 
the SYS:PUBLIC\OS2 subdirectory created during the process. 

The Netware disk volume SYS will be used to have the OS/2 V2.0 disk images as 
well as the Netware and REXX files installed onto it. The complete set of OS/2 
V2.0 images should require between 28 to 30 MB of disk storage on the SYS 
volume. The Novell Netware requester files that will be installed on the server 
will require 2 MB of storage. 

It is also assumed that a complete Novell Netware requester for OS/2 V2.0 has 
been installed on at least one client machine. This client machine will be used 
for the installation procedures explained here after and will be referred to as the 
SYSCON terminal. 

The tasks explained from this point on should be performed on the SYSCON 
terminal unless indicated otherwise. You should be logged onto the SYSCON 
terminal as a user with supervisor rights and using the Netware requester for 
OS/2 V2.0 that has been installed on it. 

There will also be some device type statements that may need to be changed in 
the CONFIG.SYS files of the LT disk. It is assumed that the person performing 
these tasks will be able to identify which statements will be required for the 
actual configuration of your network. 

The servername in the examples of this chapter is LANMAN. 

A summary of what the environment should look like before starting the server 
installation process is shown in the following chart. 



Table 3. Environment Prior to Server Setup 


Novell Server 


SYSCON terminal used for setup 


Netware 386 (3.11 or later) 


OS/2 V2.0 


30 Megabytes free space for OS/2 V2.0 
images on the SYS volume 


Novell Netware for OS/2 V2.0 


2 Megabytes free disk space for the 
client machine Netware files 


REXX/2 installed on the SYSCON 
terminal 


350 Kilobytes free space for REXX 


Logged in with supervisor rights 



Notes: 

1. OS/2 V2.0 extended attributes are only supported on Netware 3.11 or later. 

2. It is imperative that the level of code for both OS/2 V2.0 and Novell Netware 
on the SYSCON terminal used to login to the server be at the same level that 
you will be installing on the workstations. Some files will be copied from the 
SYSCON terminal onto the server for distribution to the other client 
machines. 
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7.3 Basic Installation Scenario 

This section will explain the basic installation concept, where the network 
administrator will prepare the server, LT diskettes and install OS/2 V2.0 on the 
client machine remotely. 

— Time Saver 

Ail the batch files listed in this section may be found on the Sample Code 
Disk 



7.3.1 Novell Netware Basic Installation Server Preparation 

— For multiple servers 

Should the network contain more than one Novell Netware server the 
following steps should be repeated on each of them or you must ensure that 
the preferred server function is used to connect the client machine to the 
proper server that has had the following preparation performed on it. 



The following steps are used for the basic installation scenario: 

• The building of a directory structure and the copying of all the OS/2 V2.0 
disks into them. 

These directories will be used later in the installation process to remotely 
install the complete OS/2 V2.0 base operating system onto the client 
machine using either the: 

— Dialog-driven installation 

or the 

— Response file installation. 

• The copying of the RSPINST.EXE file from the SYSCON terminal to the server 
if the response file installation method is used. 

• The copying of some necessary REXX programs onto the server to be able to 
execute any optional REXX procedures that may be included in the 
installation process. 

All of the above will be explained in the following sections in detail. 

Before doing any of the above, login to the server as a user with supervisor 
rights. Once logged in perform the following: 

• Create the directory SYS:PUBLIC\OS2\OS2IMG 

• MAP the Z: drive to the directory SYS:PUBLIC\OS2\OS2IMG 

• Create a new USER on the server called RCOS220 

• Grant this user Read and File Scan {R F) rights on the 
SYS:PUBLIC\OS2\OS2IMG directory 

• Add the MAP statement: 

MAP Z: = LANMAN\SYS:PUBLIC\OS2\OS2IMG 

to the login script for the RCOS220, where LANMAN is the network name of 
this Novell Netware server. 
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If REXX will be required to execute any batch files on the client machine during 
the installation process, perform the following: 

• Create a directory called SYS:PUBLIC\OS2\REXX 

• Grant the user RCOS220 Read and File Scan (R F) rights on the 
SYS:PUBLIC\OS2\REXX directory 

• Add the MAP statement: 

MAP R: = LANMAN\SYS:PUBLIC\OS2\REXX 

to the login script for the RCOS220, where LANMAN is the network name of 
this Novell Netware server. 

7.3.1 .1 Creating the OS/2 V2.0 Images 

The OS/2 V2.0 images must be created on the Novell Netware server by using 
the SEIMAGE utility, which is a part of the CID programs supplied with OS/2 V2.0. 
The CID programs, of which SEIMAGE is a part, must be unpacked from the OS/2 
V2.0 disks.A description of the complete process is found in 4.1, “The CID File” 
on page 17. It is suggested that you read that chapter before continuing on with 
this section. 

Once the SEIMAGE package has been unpacked and installed on the SYSCON 
terminal that you are accessing the server with, perform the following: 

• Place the OS/2 V2.0 Disk_0 in drive A: 

• Type SEIMAGE /S:A: /T:Z:\ and press Enter. 

This will create the subdirectories for each of the disks and copy all the files 
from the A: drive to the Z: drive (which has been MAPPED to the 
SYS:PUBLIC\OS2\OS2IMG directory). SEIMAGE will prompt you for each of 
the diskettes as they are required. 

When the process finishes, the OS/2 V2.0 directory structures are complete 
and the directory structure created on the server should resemble the 
following. 



SYS:PUBUC\OS2\OS2IMG 

DISK_1 

DISK_2 

DISK.3 

DISK.N 

PMDD_1 

PMDD_2 

PMDD.X 



Figure 31. Directory Structure for OS/2 V2.0 Images on Novell Netware Server 
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7.3.1 .2 Copying the RSPINST.EXE File 

If the client machine installation will be performed using the response file 
installation method, the RSPINST.EXE program is required. This file is located in 
the C:\OS2\INSTALL subdirectory of the SYSCON terminal OS/2 V2.0 
workstation. To install this program on the Z: drive of the server do the following: 

• Login to the server from the SYSCON terminal 

• Make sure the Z: drive is mapped to the SYS:PUBLIC\OS2\OS2IMG directory 
on the server 

• Type COPY C:\OS2\INSTALL\RSPINST.EXE Z:\. 

The RSPINST.EXE may also be unpacked from the original OS/2 V2.0 disk 7 by 
placing disk 7 in drive A: and issuing the following command: 

UNPACK A:\REQUIRED Z:\ /N:RSPINST.EXE 

The RSPINST.EXE program uses the response file that is specified during its 
execution. An example of the response file is shown in Figure 32. 



A1 ternateAdapter=0 

BaseFileSystem=2 

CDROM=0 

CountryCode=O01 

CountryKeyboard=US 

DefaultPrinter=91 

DiagnosticAids=l 

DisplayAdapterS) 

WindowedWIN-OS/2==0 

Documentations 

DOSEnvironmentS 

WIN-OS/2Desktop=0 

DPMIS 

ExitOnError=0 

Fonts=l 

FormatPartitionS 
Mi grateConf i gFi 1 es=0 
MoreBitmapsS) 

Mouse=l 

MousePortS) 

Opti onal Fi 1 eSystemS 
Opti onal Systemllti 1 i ti esS 
PrimaryCodePageS 
PrinterPort=l 
ProcessEnvi ronment=l 
Progresslndi cati onS 
RebootRequired=0 
REXX=1 

Seri al Devi ceSupportS 
TargetDri ve=C: 
ToolsAndGamesS 



Figure 32. OS2SE20.RSP File Contents for a Basic installation. This example has been 
shortened to show only the keywords used. 
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7.3.1 .3 Installing REXX Files on the Server 

Should the DISKPREP.CMD and PIPE.CMD programs that are shown in 
Appendix F, “Automating Fixed Disk Partitioning” on page 159 or another REXX 
batch procedure be used to prepare the fixed disk(s), REXX will be required. 
REXX is an interpretive language that provides more function than standard 
batch file commands. Because there is no operating system on the client 
machines at the point in time where we will need these programs to run, REXX 
must be installed on the server in a path accessible to the client machine. 

Create the directory SYS:PUBLIC\OS2\REXX. 

Copy the required REXX files and the FDSK.DAT, DISKPREP.CMD and PIPE.CMD 
batch files from the SYSCON terminal to the server as per Table 4. 



Table 4. Required Files on the Server for a Basic Installation. This table summarizes 
the fifes that should be present on the server and where they come from. 


From SYSCON terminal 


To SYS: 


Function 


File 


Directory 


Drive 


On 


Copy 


REXINIT.EXE 


Sample Code Disk 


R:\ 


Netware Server 


Copy 


REXX. DLL 


C:\OS2\DLL 


R:\ 


Netware Server 


Copy 


REXXINIT.DLL 


C:\OS2\DLL 


R:\ 


Netware Server 


Copy 


REXXAPI.DLL 


C:\OS2\DLL 


R:\ 


Netware Server 


Copy 


REXXUT1L.DLL 


C:\OS2\DLL 


R:\ 


Netware Server 


Copy 


REXH.MSG 


C:\OS2\SYSTEM 


R:\ 


Netware Server 


Copy 


REX.MSG 


C:\OS2\SYSTEM 


R:\ 


Netware Server 


Copy 


RSPINST.EXE 


C:\OS2\INSTALL 


Z:\ 


Netware Server 


Copy 


DISKPREP.CMD 


Sample Code Disk 


Z:\ 


Netware Server 


Copy 


PIPE.CMD 


Sample Code Disk 


Z:\ 


Netware Server 


Copy 


FDSK.DAT 


Sample Code Disk 


Z:\ 


Netware Server 



REXINIT.EXE 

The REXINIT.EXE program is located on the Sample Code Disk that 
accompanies this document or may be acquired from an IBM system 
engineer. 



The following diagram illustrates what the directory structures should look like 
for a basic installation, as well as where the files that must be copied to the 
server are copied from. 
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Figure 33. Example of Netware Server Basic Installation . Note that this example only 
shows the files and directories that are to be copied . There are others present that are not 
shown . 



This concludes the preparation of the server section for a basic installation. 



7.3.2 Basic OS/2 V2.0 Installation Client Portion 

This section describes the procedure required for a network administrator to 
prepare the LT diskettes and install a basic OS/2 V2.0 client machine. The basic 
installation process will not install the Novell Netware code nor collect the 
installation log files. It also assumes that each of the client machines will be 
configured the same, in the case of a response file installation. 

7.3.3 Preparation of the Novell LT Diskettes 

To install OS/2 V2.0 on a client machine where there is no existing OS/2 
operating system or hard disk partition, the client machine will need to be 
booted from diskette and have the installation process started from there. This 
section will describe the process of preparing the Novell LT diskettes used to 
initiate the installation process. 

There are two diskettes required to boot an OS/2 V2.0 machine. They are: 

• The install disk 

This disk is an exact replica of the original install disk that is shipped with 
OS/2 V2.0. 

• Disk_1 

Otherwise known as the LT disk. This is a copy of the original Disk_1 with 
some minor changes. 
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The function of the Novell LT disk is to: 

• Start the client machine under OS/2 V2.0 from diskette 

• Load the required device drivers for the Netware requester 

• Establish a connection to the Novell Netware server 

• Partition the hard disk(s) and format the partitions (optional) 

• Remotely install the OS/2 V2.0 operating system on the client machine. 

The Novell LT disks must be prepared using the SEDISK utility that is a part of 
the CID program supplied with OS/2 V2.0. 

To prepare the disks using the SEDISK program, follow the procedure explained 
in 4.1.2, “SEDISK" on page 19. The source drive will be the 
SYS:PUBLIC\OS2\OS2IMG directory on the server (that has been mapped to the 
Z: drive) and the target will be the A: drive. 

During a dialog-driven installation the client machine will have to be rebooted 
during the install process. This is to load the graphical support required during 
the second part of the process. The first stage of the installation process copies 
any device related statements from the CONFIG.SYS on the A: drive as well as 
the drivers themselves to the root of the C: drive. This is to allow the network 
connection to be re-established during the reboot process. It is for this reason 
that the files listed in Table 5 on page 74 must be copied to the root of the LT 
disk. 

During the reboot process there is also a small program called LOOP.CMD 
which is called from a call statement in the CONFIG.SYS file. The purpose of this 
program is to act as a delay to allow the network connection to be established 
prior to attempting to perform a login. The LOOP.CMD must be on the LT disk so 
that it will be copied to the root of C: and run during the reboot. Also the call 
statement to run it must be in the CONFIG.SYS of A: so that it will be migrated to 
the CONFIG.SYS on C: 

The call statement requires the CMD.EXE file to be executed to be able to run 
the LOOP.CMD file. During the reboot the CMD.EXE file is located in the C:\OS2 
subdirectory. For this reason it is necessary to create an OS2 subdirectory on 
the LT disk and copy CMD.EXE into it. 

To complete the above perform the following: 

• Create the directory OS2 on the LT disk 

• Copy CMD.EXE from the root of the LT disk to A:\OS2 

• Copy the LOOP.CMD file from the Sample Code Disk onto the LT disk 

The LOOP.CMD can also be created using a text editor. The contents are 
listed in Figure 34 on page 74 
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GECHO OFF 
: START 

IF EXIST L:\0S2\L0GIN.EXE GOTO EXIT 
GOTO START 
: EXIT 

L:\0S2\L0GIN RC0S220 
EXIT 



Figure 34. Contents of LOOP.CMD File 

Some other required files will need to be added onto the LT disk to establish the 
IPX network connection to the Netware server. This process may differ 
somewhat from one environment to another. In this example there is a 
token-ring connection being used, so the Netware device driver required for that 
adapter will be loaded. If the adapter being used is a different one, replace the 
network drivers listed with those required to support the appropriate type of 
connection. 

I Important 

The network drivers must be copied to the root directory of the LT disk. 



The following chart lists the required files and where they are to be copied from. 



Table 5. Token Ring Netware Required Files . These fifes should be copied from the 
directory listed on the 0 FROM 0 section to the drive listed in the 'TO 0 section listed 
using the COPY command . This list is only valid for a token-ring network. 


Copy from 


To 


Machine 


File Path / name 


Machine 


Drive 


SYSCON terminal 


C:\NETWARE\NWCONFIG.DLL 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\IPXCALLS.DLL 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWCALLS.DLL 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\LSLSYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\TOKEN.SYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\ROUTE.SYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWDAEMON.EXE 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWREQ.SYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWIFS.IFS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\IPX.SYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NET.MSG 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NETH.MSG 


SYSCON terminal 


A:\ 



7.3.3.1 Additional LT Required Programs 

There are some additional programs that will be required to be executed on the 
client machine during the installation process. This section will explain these 
additional operations, which are: 

• Fixed disk partitioning and formatting (optional) 

• Dialog-driven installation 
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• Response file installation. 

7.3.3.2 Fixed Disk Partitioning and Formatting 

Should the process of partitioning and formatting the fixed disk of the client 
machine be required, a separate procedure may be required. There is a sample 
REXX procedure that may be used to partition and format the fixed disk called 
DISKPREP.CMD in Appendix F, "Automating Fixed Disk Partitioning" on 
page 159. 

Should the example code or some other program that is developed be used to 
create and format the partitions, it should be added to the STARTPDI.CMD or 
STARTRFI.CMD batch files (explained later in this section) just after logging in. 

7.3.3.3 Dialog-Driven Installation Versus Response File 
Installation 

There are two methods of completing a remote installation of OS/2 V2.0 on a 
LAN. They are dialog-driven installation and response file installation. In both 
cases there will be a requirement to add a CMD file to the LT disk and a 
modification to the CONFIG.SYS be performed. A dialog-driven installation 
requires input by the person performing the installation where a response file 
installation is a more automated way to install the OS/2 V2.0 operating system 
and uses a response file approach to configure the client machine. 

The following paragraphs will explain the two options and the steps required to 
complete them. For more information on dialog-driven installation or response 
file installation please refer to 2.2, "Attended Redirected Installation” on page 4. 

• Dialog-Driven Installation 

The dialog-driven installation requires manual intervention by the person 
installing the OS/2 V2.0 operating system on the client machine. This method 
of installation is very similar to a manual installation method where the user 
is prompted for the diskettes and responds to questions concerning the 
system configuration. In a dialog-driven installation, however, there is no 
need to insert the diskettes during the install process. The disk images are 
read from the server so the user only has to answer the configuration 
questions when prompted for them. 

If the dialog-driven installation method of installation will be used modify the 
shell statement in the CONFIG.SYS statement on the LT disk to look like the 
following : 

SET OS2_SHELL = CMD.EXE IK A:\STARTPDI.CMD 

and create the STARTPDI.CMD file on the LT disk. 

The contents of the STARTPDI.CMD file are: 
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Detach R:\REXINIT (optional for REXX) 

PAUSE 

CALL Z:\DISKPREP.CMD 
IF ERRORLEVEL 4 GOTO END 

A: 

Z:\DISK 1\SYSINST2.EXE Z:\ 

SEND 

9 ECHO OFF 

ECHO "Partitioning not done. Cannot complete Installation" 



Figure 35. STARTPDI.CMD File Contents on Novell LT Disk. The highlighted lines are 
used for the DISKPREP.CMD program and may be left out if REXX is not required or a 
disk preparation program is not used. 

There are some CONFIG.SYS file considerations also. For a dialog-driven 
installation they are: 

— Change the SET OS2_SHELL statement (already mentioned) 

— Add Z:\DISK_1; to the Path statement 

If REXX is required during the installation process and the REXX files 
have been installed on the server as documented in the server setup 
section, make the following changes: 

- Add R:\ to the Dpath and Libpath statements 

- Add the SET SOURCEPATH = Z:\ statement 

This indicates where the OS/2 V2.0 images are to be read from. 

— Add the required Netware device statements 

- Add the CALL = \OS2\CMD.EXE /K LOOP.CMD statement. 

Note that the CALL statement is only required for a dialog-driven 
installation. 

A copy of the CONFIG.SYS used for this example follows. 



76 



OS/2 V2.0 Remote Installation 





ITSC Technical Bulletin Evaluation 

Technical Bulletin Title: 



Technical Bulletin Form Number: 



This is an evaluation form to assess the quality of ITSC publications. Your feedback will help maintain the 
high quality of ITSC standards. Please fill out this questionnaire and send it to the address on the back of 
this page. No postage stamp is required if mailed in the U.S. Elsewhere, you may choose to have your 
IBM Marketing Representative forward your reply to the address listed on the reverse side of this form. 

Date publication was ordered (MM/DD/YY) / / 

Date publication was received (MM/DD/YY) / / 



Please rate on a scale of 1 to 5 the subjects below. 
(1 = very good, 2 = good, 3 = average, 4 = 



Technical Bulletin organization 
Accuracy of the information 
Relevance of the information 
Completeness of the information 
Value of illustrations 



poor, 5 = very poor) 

Grammar/punctuation/spelling 
Ease of reading and understanding 
Ease of finding information 
Lack of redundant information 
Overall satisfaction 



Please answer the following questions: 

a) Was the level of detail of the information adequate? Yes No 

b) Did you find information duplicated that was available in other Yes No 

IBM publications? 

If yes, please name the publication: 



c) Was the bulletin published in time for your needs? 

d) Did this bulletin meet your needs? 

If no, please explain: 



Yes No. 

Yes No 



Comments/Suggestions: 



Thank you for your feedback. 

Your name, company name, and address (optional): 



ITSC Technical Bulletin Evaluation Form 



i 




POSTAGE WILL BE PAID BY ADDRESSEE: 
IBM International Technical Support Center 
Department H52, Building 930 
P.O. Box 950 

Poughkeepsie, New York 12602 
U.S.A. 




ATTN: Quality Coordinator 



KKIIN I tU IN I lit U.b.A 





buffers=32 

iop1=yes 

memman=noswap 

protshell= sysinstl.exe 

SET 0S2_SHELL=CMD.EXE /K A:\STARTPDI.CMD 

protectonly=yes 

LIBPATH*. ;\;\0S2\DLL;R:\ 

ifs=hpfs.ifs /c:64 /autocheck:c 

pauseonerror=no 

codepage=850 

de vi nf o=kbd , us , keyboard . dcp 

devinfo=scr,ega,vtbl850.dcp 

device=\dos.sys 

device=\mouse.sys 

rem device=c:\ibmlds\lds.sys 

SET PATH°\;\0S2\SYSTEN;\0S2\INSTALL;Z:\DISK 1; 

SET DPATH=\ ; \0S2\SYSTEH; \0S2\INSTALL ; R j \ ; 

set keys=on 

basedev=print01.sys 

basedev=ibmlflpy.add 

basedev=ibmls506.add 

basedev=ibm2f1py.add 

basedev=i bm2adsk . add 

basedev=i bm2scsi .add 

basedev=i bmi ntl3. i 13 

basedev-os2dasd.dmd 

SET SOURCEPATK»Z:\ 

REN — NetWare Requester statements BEGIN 

DEVICE=A:\LSL.SYS 

REH — Network Adapter Card — 

DEVI CE=A:\T0KEN. SYS 
DEVICE=A:\ROUTE.SYS 
DEVICES: \IPX.SYS 
DEVICES : \NWREQ . SYS 
IFS«A:\NWIFS.IFS 
RUN«A: \NWDAENON.EXE 

REN — NetWare Requester statements END — 

CALL-AOS2\CKD.EXE /K LOOP.CHD 

Figure 36. Example of CONFIG.SYS on the LT Diskette for a Dialog-Driven Installation. 
The lines particular to the installation are shown highlighted. 

• Response file installation 

The response file installation process uses the concept of a response file 
that contains all the necessary configuration information as input to the 
installation process. There is no user intervention required once the process 
has started and there is no reboot required until the complete installation 
process is finished. The disk images are read from the server and the 
response file can be either on the LT disk or on the Z: drive of the server. If 
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the response file installation method will be used, modify the shell statement 
in the CONFIG.SYS statement on the LT disk to look like the following: 

SET OS2_SHELL = CMD.EXE /K A:\STARTRFB.CMD 

and create the STARTRFB.CMD file on the LT disk. 

The contents of the STARTRFB.CMD file are: 



: START 

IF EXIST L:\0S2\L0GIN.EXE GOTO EXIT 
GOTO START 
:EXIT 
L: 

CD\0S2 

LOGIN RCOS220 

Detach R:\REXINIT (optional for REXX) 

PAUSE 

CALL Z:\DISKPREP.CND 
IF ERRORLEVEL 4 GOTO END 

A: 

Z:\RSPINST Z:\OS2SE20.RSP 

:END 

0ECHO OFF 

ECHO "Partitioning not done. Cannot complete installation" 



Figure 37. STARTRFB.CMD File Contents for a Basic Installation. The highlighted lines 
are used for the DISKPREP.CMD program and may be left out if REXX is not required or a 
disk preparation program is not used. 

If the response file installation method of installation is used then an 
OS2SE20.RSP file must have been created during the server setup on the 
SYS:PUBLIC\OS2\OS2IMG directory of the server. This file may also be 
placed on the A: drive. An example of a response file may be seen in 
Figure 32 on page 70. 

There are some CONFIG.SYS file considerations also. For a response file 
installation they are: 

• Change the SET OS2_SHELL statement (already mentioned) 

• Add Z:\DISK_1; to the Path statement 

If REXX is required during the installation process and the REXX files have 
been installed on the server as documented in the server setup section, 
make the following changes: 

— Add R:\ to the Dpath and Libpath statements 

• Add the SET SOURCEPATH=Z:\ statement 

This indicates where the OS/2 V2.0 images are to be read from. 

• Add the required Netware device statements. 

A copy of the CONFIG.SYS used for this example follows. 
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buffers=32 

iop1=yes 

memman=noswap 

protshell= sysinstl.exe 

SET 0S2_SHELL=CMD . EXE /K A:\STARTRFI.CMD 

protectonly=yes 

LIBPATH=. ;\;\0S2\DLLjR:\ 

ifs=hpfs.ifs /c : 64 /autocheck: c 

pauseonerror=no 

codepage=850 

devi n f o=kbd , us , key board . dcp 

devi nfo=scr,ega,vtbl 850. dcp 

device=\dos.sys 

device=\mouse.sys 

rem device=c:\ibmlds\lds.sys 

SET PATH=\ ; \0S2\SYSTEM; \0S2\ INSTALL ; Z : \ DISK 1; 

SET DPATH=\ ; \0S2\SYSTEH; \0S2\ INSTALL ; R : \ ; 

set keys=on 

basedev=pri nt01 . sys 

basedev=ibmlflpy.add 

basedev=i bmls506. add 

basedev=i bm2f 1 py . add 

basedev=ibm2adsk.add 

basedev=ibm2scsi .add 

basedev=i bmi ntl3. i 13 

basedev=os2dasd.dmd 

SET SOURCEPATH=Z:\ 

REH — NetWare Requester statements BEGIN — 

DEVICE=A:\LSL.SYS 

REH — Network Adapter Card — 

DEVICES: \T0KEN. SYS 
DEVICES: \R0UTE. SYS 
DEVICE=A:\IPX.SYS 
DEVICE=A : \NWREQ . SYS 
IFS=A:\NWIFS.IFS 
RUN=A: \NWDAEHON.EXE 

REM — NetWare Requester statements END — 



Figure 38. Example of CONFIG.SYS on the LT Diskette for a Response File Installation. 
The lines particular to the installation are shown highlighted. 

A directory listing of the LT disk follows: 
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000000 


BIO 


F80703 


BIO 


SCREEN01 SYS 


ABI0S 


SYS 


F80704 


BIO 


SCREEN02 SYS 


ANSICALl 


DLL 


F80902 


BIO 


SESMGR DLL 


BKSCALLS 


DLL 


F80903 


BIO 


SIPANEL1 DLL 


BMSCALLS 


DLL 


F80904 


BIO 


SYSINST1 EXE 


BVHINIT 


DLL 


F80A00 


BIO 


SYSINST2 EXE 


BVSCALLS 


DLL 


F80AO1 


BIO 


SYSLEVEL 0S2 


CL0CK01 


SYS 


F80A02 


BIO 


VI0CALLS DLL 


CL0CKQ2 


SYS 


F80C0O 


BIO 


VTBL850 DCP 


CMD 


EXE 


F8OD00 


BIO 


W020100 BIO 


CONFIG 


SYS 


F80D01 


BIO 


W020101 BIO 


COUNTRY 


SYS 


F81000 


BIO 


W0 50000 BIO 


IBM2ADSK 


ADD 


F81B00 


BIO 


W050100 BIO 


IBM2FLPY 


ADD 


F88000 


BIO 


W050101 BIO 


IBM2SCSI 


ADD 


FC0400 


BIO 


WO60100 BIO 


IBM1FLPY 


ADD 


FC04O3 


BIO 


W0FO0O0 BIO 


IBM1S5Q6 


ADD 


FC0500 


BIO 


DISK NUM 


IBMINT13 


113 


FDISK 


COM 


STARTRFI CMD 


0S2SCSI 


DMD 


HARDERR 


EXE 


OS2SE20 RSP 


0S2DASD 


DMD 


HPFS 


IFS 


NWC0NFIG DLL 


TESTCFG 


SYS 


KBD01 


SYS 


IPXCALLS DLL 


DOS 


SYS 


KBD02 


SYS 


NWCALLS DLL 


D0SCALL1 


DLL 


KBDCALLS 


DLL 


LSL SYS 


F8O0O0 


BIO 


KEYBOARD DCP 


TOKEN SYS 


F80100 


BIO 


M0UCALLS DLL 


ROUTE SYS 


F80200 


BIO 


MOUSE 


SYS 


NWDAEM0N EXE 


F80402 


BIO 


MSG 


DLL 


NWREQ SYS 


F80403 


BIO 


NAMPIPES 


DLL 


NWIFS IFS 


F80404 


BIO 


NLS 


DLL 


IPX SYS 


F80600 


BIO 


NPXEMLTR DLL 


NET MSG 


F80700 


BIO 


0S2CHAR 


DLL 


NETH MSG 


F80701 


BIO 


PRINT01 


SYS 


QUECALLS DLL 


F80702 


BIO 


PRINT02 


SYS 


LOOP CMD 



Figure 39. Directory Listing of Novell LT Disk 



7.3.4 Basic Installation of OS/2 V2.0 on the Client Machines 

This section will describe the procedures to be followed to perform the actual 
basic remote installation of OS/2 V2.0 on the client machine. It is assumed that 
there is a network connection on the client machine and that the Server and LT 
preparations have been completed prior to starting this process. 



This installation method of OS/2 V2.0 assumes that the client machine is either: 

• A new Personal Computer that has not been partitioned or formatted yet, in 
which case the disk may be partitioned during the install process using one 
of the following: 

- Using a fixed disk partitioning program such as in Appendix F, 
“Automating Fixed Disk Partitioning" on page 159. 

- Selecting not to accept the default drive, during a dialog-driven 
installation. 



or 

• An existing Personal Computer which has one or multiple partitions on it and 
the partition which is to have OS/2 V2.0 installed on it has been set as 
"Installable" (for Boot Manager) or "Active". 
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Should there be programs to be migrated from a DOS or Windows environment 
there are some keywords that need to be set in the response file for an 
response file installation or questions to be answered during a dialog-driven 
installation. For more information on migration, please refer to 3.3, “Upgrading 
DOS Systems to OS/2 V2.0" on page 10. 

To begin the installation process: 

• Place the OS/2 V2.0 Installation disk in the A: drive and power on the client 
machine. 

• When prompted, place the LT disk in drive A: and press Enter. 

This will begin the installation process. 

• The LOOP.CMD program will check if the server connection has been 
established yet by looking for the existence of a known file on the server. 
The program will loop until the file is found. Then the LOOP.CMD program 
will perform a login to the server as user RCOS220. 

Depending on whether you have selected to use the dialog-driven installation or 
the response file installation the sequence of events from this point differs. The 
following sections will guide you through the process that is followed for each of 
them. 



7.3.4.1 Dialog-Driven Installation 

Once the CONFIG.SYS has completed processing it will run the STARTPDI.CMD 
that was entered on the OS2_SHELL statement. 

The following explains the steps that the STARTPDI.CMD program goes through: 

• The REXINIT.EXE program is started if the statement was added to the 
STARTPDI.CMD batch file. 

• The DISKPREP.CMD program is run if it was added to the STARTPDI.CMD 
file and the OS2V20 partition is set to "Installable". 

• SYSINST2.EXE is run from the Z:\DISK_1 subdirectory that was created in 
7.3.1, “Novell Netware Basic Installation Server Preparation” on page 68. 

• The images are read from drive Z: to install OS/2 V2.0 on the client machine 
target drive. 

The contents of the STARTPDI.CMD program can be seen in Figure 35 on 
page 76. 

During the dialog-driven installation process there will be some configuration 
questions to answer and the system will need to be rebooted after the fifth disk 
is read from the server. When prompted remove the diskette from the A: drive 
and reboot the workstation. 

When the system is rebooted after the fifth disk, it will continue loading all the 
disk images and ask for some more configuration information. Each client 
machine may very easily be configured differently using this method, as the 
configuration information is prompted for on each client machine. 
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I USEFUL TIP 



The progress of the installation may also be monitored from the Novell 
Netware server by using the MONITOR function and viewing the RCOS220 
connection for Open Files. 



When the process is complete a panel will be displayed stating that the 
installation has completed. Although the panel displayed says to remove the 
diskette from the A: drive, there is no diskette there due to the fact that the 
images were read from a remote server. Simply reboot the workstation. When it 
restarts, the client machine starts with a completely operational version of OS/2 
V2.0 on it! 



7.3.4.2 Response File Installation 

Once the CONFIG.SYS has completed processing it will run the STARTRFB.CMD 
program that was entered on the OS2 SHELL statement as described in 7.3.3.1, 
“Additional LT Required Programs” on page 74. 

The following explains the steps that the STARTRFB.CMD program goes through, 
which is listed in Figure 37 on page 78. 

• The program connects to the L: drive on the server. 

• A login is performed using the RCOS220 user ID. 

• The REXINIT.EXE program is started if the statement was added to the 
STARTRFB.CMD batch file. 

• The DISKPREP.CMD program is run if it was added to the STARTRFB.CMD 
file and the OS2V20 partition is set to "Installable". 

• The RSPINST program is started and reads the OS2SE20.RSP file for the 
system configuration input. 

• The OS/2 V2.0 images are read from the drive specified with the SET 
SOURCEPATH environment variable in the CONFIG.SYS file. 

The diagram in Figure 40 on page 83 shows the required mapping for a basic 
installation as well as the installation environment. 
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Figure 40. Client Environment for a Basic Installation 

| USEFUL TIP 

The progress of the installation may also be monitored from the Novell 
Netware server by using the MONITOR function and viewing the RCOS220 
connection for Open Files. 



When the process is complete a panel will be displayed stating that the 
installation has completed. Remove the diskette from the A: drive and reboot 
the workstation. When it restarts, the client machine starts with a completely 
operational version of OS/2 V2.0 on it! 



7.4 Advanced OS/2 V2.0 Installation Scenario 

This section describes the procedure required for a network administrator to: 

• Prepare the server for an advanced installation 

• Prepare the LT diskettes 

• Partition and format the client machine fixed disk if required 

• Perform the client machine installation 

• Install the Novell Netware requester code on the client machine 

• Collect the installation log from the client machine back to the server. 
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7.4.1 Advanced Installation Assumptions 

All of the assumptions listed on 7.2, “Netware Assumptions” on page 66 apply to 
this section. 

— Time Saver — — . 

All the batch files listed in this section may be found on the Sample Code 
Disk 



7.4.2 Novell Netware Advanced Installation Server Preparation 

For multiple servers — 

Should the network contain more than one Novell Netware server the 
following steps should be repeated on each of them or you must ensure that 
the preferred server function is used to connect the client machine to the 
proper server that has had the following preparation performed on It. 



The following steps are used for an advanced installation scenario: 

• The building of a directory structure and the copying of all the OS/2 V2.0 
disks into them 

These directories will be used later in the installation process to remotely 
install the complete OS/2 V2.0 operating system onto the client machine 
using the response file installation. 

• The copying of the RSPINST.EXE file from the SYSCON terminal to the server 

• The copying of some necessary programs onto the server to be able to 
execute the REXX procedures included in the installation process. 

All of the above will be explained in the following sections in detail. 

Before doing any of the above, login to the server as a user with supervisor 
rights. Once logged in perform the following: 

• MAP the Z: drive to the SYS:PUBLIC\OS2\OS2!MG directory. 

• Create a directory called SYS:PUBLIC\OS2\REXX to install the required 
REXX programs on. 

• Map the drive letter R: to the SYS:PUBLIC\OS2\REXX directory. 

• Copy the REXINIT.EXE program that is on the Sample Code Disk onto the R: 
drive. 

• Create a directory called SYS:PUBLIC\OS2\NWFILES to install the Novell 
Netware requester files onto. 

This will be used for downloading the Netware requester files onto the client 
machines during the installation process. 

Suggestion: Do not use the NETWARE directory name as this may cause 
confusion to anyone who works on the server. Novell typically installs itself 
into the Netware directory and should be considered reserved. 

• MAP the N: drive letter to the SYS:PUBLIC\OS2\NWFILES directory. 

The next step requires the original NETWARE OS/2 Requester disk. 
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• Unpack all the files from the NETWARE OS/2 Requester disk \REQUESTR 
subdirectory onto the N: drive. Do this by placing the NETWARE OS/2 
Requester disk in drive A: and typing: 

A:\NWUNPACK \REQUESTR\*.* N: 

If the original disk is not available the files may also be copied from the 
NETWARE directory of the SYSCON terminal, onto the 
SYS:PUBLIC\OS2\NWFILES directory on the server. To do so type: 

XCOPY C:\NETWAREW N: 

Be Careful: Performing the XCOPY command as shown above assumes 
that none of the NETWARE requester files were deleted from the 
SYSCON terminal since it was installed. 

• Create the user ID's for the client machines that will be installed using the 
advanced installation method. 

• Grant these user ID's Read and File Scan (R F) rights on the following 
directories: 

SYS:PUBLIC\OS2\OS2IMG 

SYS:PUBLIC\OS2\NWFILES 

SYS:PUBLIC\OS2\REXX 

• Add the MAP statement 

MAP X: = LANMAN\SYS:"user ID" 

to the login script for each of the user ID's created where "LANMAN" is the 
network name of this Novell Netware server and "user ID" is the user ID that 
was just created. 

— When modifying login scripts 

It is assumed that the home directory for the user ID is SYS:"user ID" 
which was the default directory assigned when the userid was created. 
Should the users home directory not be one assigned by the default, 
ensure that the actual home directory for the userid is used in the MAP 
statement for drive X:. 



Should there be any customization of OS/2 V2.0 required during the 
installation process, it will be done using an INCLUDE statement in the 
OS2SE20.RSP response file. The INCLUDE keyword will call the X:\INDIV.RSP 
file. This file is required in each of the user ID's home directories that will 
require the customization. The contents of the file must follow the rules for 
an INCLUDE file which is explained in A.1, “Keyword Description” on 
page 118. An example of a valid INDIV.RSP files is shown next. 



* Response file for a workstation where the printer installed 

* is of another type than the one defined in the OS2SE20.RSP 

* file used in the example. 

DefaultPrinter=65 



Figure 41. Example of an INDIV.RSP File Contents 

• Create a file called NWINST.CMD on the N: drive 
The contents of the NWINST.CMD file as shown in Figure 42 on page 86. 
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/* REXX procedure to upgrade CONFIG.SYS for OS/2 2.0 */ 

/* Adds the C:\NETWARE to path, dpath and libpath statements */ 

address cmd 
'Gecho off' 

env* '0S2ENVIRCNMENT' /* Access the OS2 environment*/ 

CltDrv»value('TargetDr1ve’,,env) /* Gets drive letter from 0S2*/ 

NWDrv»'C:' /* Sets drive letter for NW */ 



/* V 
/* The targetdrive for 0S2 was read from the response file keyword */ 
/* TARGETDRIVE. 

/* V 
/* The NWDrv letter is the drive where NETWARE will be installed. */ 
/* This will typically be the same as for 0S2 but you may specify */ 
/* any valid drive letter, if you wish. */ 



do while lines(CltDrv[ j '\config.sys') 
it ■ 1 inein (Cl tDrv | | '\config.sys') 
it ■ translate(it) 
if pos ( ’SET PATH' , it ) o 0 then 
do 

it - it !! NWDrv [ J '\NETWARE' 
end 

if pos ( 'SET DPATH' , it ) o 0 then 
do 

it « it JJ NWDrv JJ'\NETWARE' 
end 

if pos ( 'LIBPATH' , it ) o 0 then 
do 

it - it !! NWDrv !!'\NETWARE' 



/* Do until end of file */ 
/* Read first line */ 
/* Make everything UPPERCASE*/ 
/* If SET PATH is in line */ 

/* Add (NWDrv) :\NETWARE */ 

/* If SET DPATH is in line */ 

/* Add (NWDrv) :\NETWARE */ 

/* If LIBPATH is in line*/ 

/* Add (NWDrv) :\NETWARE */ 



end 

call lineout CltDrv! j '\config.new 1 , it /* Write line to config.new */ 
end 



/* close the files */ 

call stream CltDrvj J '\config. new' , 'c', 'close' 
call stream CltDrv' | '\config.sys', 'c', ’close' 

'copy' CltDrvj | '\config.new' Cl tDrv [ | ’\config.sys’ 

'del 'CltDrvj | '\config. new’ 

/* */ 

/* The following lines add the required device statements to the */ 

/* Config.sys for the NETWARE network. Includes TOKEN RING drivers only */ 

/* */ 

call lineout CltDrv' | '\config.sys' , ' ' 
call lineout CltDrv' j '\config.sys', 'REM' 

call lineout CltDrv' | '\config,sys', 'REM Beginning of Netware device statements' 
call lineout CltDrvj | '\config.sys', 'REM 1 

call lineout CltDrvj J '\config.sys', ' DEVICE*' NWDrv J J '\NETWARE\LSL.SYS' 
call 1 i neout Cl tDrv J \ ’ \conf i g . sys • , ' DEVI CE» ' NWDrv J \ ' \NETWARE\TCKEN . SYS ' 
call lineout CltDrvj \ '\conf ig. sys', 'DEVI CE«' NWDrv J J '\NETWARE\RCUTE. SYS' 
call 1 i neout C 1 tDrv J \ ' \conf i g . sys 1 , ' DEVICE- 1 NWDrv J \ ' \NETWARE\ IPX.SYS ' 
call lineout CltDrvj J '\config.sys' , ' DEVICE** ' NWDrv J S '\NETWARE\NWREQ.SYS' 
call lineout CltDrvj J '\config.sys' , 'IFS-'NWDrvJ J '\NETWARE\NWIFS. IFS' 
call lineout CltDrvj J '\config.sys', 'RUN- 'NWDrv J J '\NETWARE\NWDAEMON.EXE* 
call lineout CltDrvj J '\config.sys', 'REM' 

call lineout CltDrvj J '\config. sys', 'REM - NetWare Requester statements END 
call lineout CltDrvj [ '\config. sys 1 
/* */ 

/* This section will make the NWDrv NETWARE directory and */ 

/* copy the Netware requester files into it from the server */ 

/* */ 

•md' NWDrvJ J'\NETWARE' 

'copy Ni\*.* 'NWDrvJ J '\NETWARE' 

/* */ 

/* The next line copies the 0S2 installation log to the server */ 

'copy 'CltDrvj J '\OS2\INSTALL\INSTALL.LOG X: \ ' 

/* */ 

/* END OF BATCH FILE */ 



Figure 42. Contents of the NWiNST.CMD Fife. Called by the UserExit of the 
OS2SE20.RSP response file and used to complete the Netware requester installation on 
the client machine's at the end of the OS/2 V2.0 installation. 
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7.4.2.1 Copying the RSPINST.EXE File 

The client machine installation will be performed using the response file 
installation method, therefore the RSPINST.EXE program is required. This file is 
located in the C:\OS2\INSTALL subdirectory of the SYSCON terminal OS/2 V2.0 
workstation that is being used to perform these tasks. To install this program on 
the Z: drive of the server do the following: 

• Log into the server from the SYSCON terminal 

• Make sure the Z: drive is mapped to the SYS:PUBLIC\OS2\OS2IMG directory 
on the server 

• Type COPY C:\OS2\INSTALL\RSPINST.EXE Z:\. 

The RSPINST.EXE program uses the response file that is specified during its 
execution. In this case the OS2SE20.RSP file from the Z: drive is used. An 
example of the file is shown next. The response file may be created on the Z: 
drive using a text editor or the SAMPLE.RSP may be unpacked from the OS/2 
V2.0 disk as described in 4.2.2, “SAMPLE.RSP” on page 21 and modified. 



AT ternateAdapter=0 

BaseFile$ystem=2 

CDROM=0 

CountryCode=001 

CountryKeyboard=US 

DefaultPrinter=91 

DiagnosticAi ds=l 

DisplayAdapter=0 

Wi ndowedWIN-0S/2=0 

Documentations 

DOSEnvi ronmentS 

WIN-OS/2Desktop=0 

DPMI=1 

Exi tOnError=0 
Fonts=l 

FormatPartitionS 

Incl ude=X:\INDIV.RSP 

Mi grateConf i gFi 1 es=0 

MoreBi tmaps=0 

Mouse=l 

MousePort=0 

Opti onal Fi 1 eSystemS 

Opti onal SystemUti 1 i ti esS 

PrimaryCodePageS 

PrinterPortS 

ProcessEnvi ronmentS 

Progresslndi cati onS 

RebootRequired=0 

REXXS 

Seri al Devi ceSupportS 
TargetDri ve=C: 

ToolsAndGamesS 
USEREX I T=N: \NWINST.CMD 

Figure 43. OS2SE20.RSP File Contents for an Advanced Installation. This example has 
been shortened to show only the keywords used. 
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7.4 .2.2 Installing REXX Files on the Server 

The NWINST.CMD program as well as the disk partitioning program that is 
shown in Appendix F, “Automating Fixed Disk Partitioning” on page 159 require 
the use of REXX. REXX is an interpretive language that provides more function 
than standard batch file commands. Because there is no operating system on 
the client machines at the point in time where we will need these programs to 
run, REXX must be installed on the server in a path accessible to the client 
machine. 

A directory called SYS:PUBLIC\OS2\REXX was created during the server setup. 

Copy the required REXX files from the SYSCON terminal to the server as per 
Table 6. 



Table 6. Required files to support an Advanced Installation. This table summarizes the files that should be 
present on the server and where they come from. 


Operation 


Machine 


File Path / Name 


- 


Machine 


Drive 


Copy from 


Sample Code Disk 


A:\REXINIT.EXE 


To 


Server 


RA 


Copy from 


SYSCON terminal 


C:\OS2\DLL\REXX.DLL 


To 


Server 


R:\ 


Copy from 


SYSCON terminal 


C:\OS2\DLL\REXXINIT.DLL 


To 


Server 


R:\ 


Copy from 


SYSCON terminal 


C:\OS2\DLL\REXXAPI.DLL 


To 


Server 


R:\ 


Copy from 


SYSCON terminal 


C:\OS2\DLL\REXXUTILDLL 


To 


Server 


R:\ 


Copy from 


SYSCON terminal 


C:\OS2\SYSTEM\REXH.MSG 


To 


Server 


R:\ 


Copy from 


SYSCON terminal 


C:\OS2\SYSTEM\REX.MSG 


To 


Server 


R:\ 


Copy from 


SYSCON terminal 


C:\OS2\INSTALL\RSPINST.EXE 


To 


Server 


Z:\ 


NWUnpack 


Novell OS2 disk 


A:\REQUESTR\V 


To 


Server 


N:\ 


Copy 


Sample Code Disk 


NWINST.CMD 


On 


Server 


N:\ 


Create 


~ 


OS2SE20.RSP 


On 


Server 


Z:\ 



I REXINIT.EXE 



The REXINIT.EXE program is located on the Sample Code Disk this 
accompanies this document or may be acquired from an IBM Systems 
Engineer. 



The following diagram illustrates what the directory structures should look like 
for an Advanced Installation as well as where the files that must be copied to the 
server are copied from. 
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Figure 44. Example of an Advanced Installation Server. Note that this example only 
shows the files and directories that are to be copied. There are others present that are not 
shown. 



This concludes the preparation of the server section for an advanced installation. 

7.4.3 Preparation of the Novell LT Diskettes 

To install OS/2 V2.0 on a client machine where there is no existing OS/2 
operating system or hard disk partition, the client machine will need to be 
booted from diskette and have the installation process started from there. This 
section will describe the process of preparing the Novell LT diskettes used to 
initiate the installation process. 

There are two diskettes required to boot an OS/2 V2.0 machine. They are: 

• The install disk 

This disk is an exact replica of the original install disk that is shipped with 
OS/2 V2.0 

• Disk_1 

Otherwise known as the LT disk, this is a copy of the original Disk_1 with 
some minor changes. 

The function of the Novell LT disk in an advanced installation is to: 

• Start the client machine under OS/2 V2.0 from diskette 

• Load the required device drivers for the Netware requester 

• Establish a connection to the Novell Netware server 

• Partition the hard disk(s) and format the partitions (optional) 
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Remotely install the OS/2 V2.0 operating system on the client machine 
Remotely install the Novell Netware requester code on the client machine 
Copy the OS2 installation log to the server. 



The Novell LT disks must be prepared using the SEDISK utility, which is a part of 
the CID program supplied with OS/2 V2.0. 

To prepare the disks using the SEDISK program, follow the procedure explained 
in 4.1.2, “SEDISK” on page 19. The source drive will be the Z: drive on the 
server and the target will be the A: drive on the client machine that you are 
working on. 

Next some required files will need to be added onto the LT disk to establish the 
IPX network connection to the Netware server. This process may differ 
somewhat from one environment to another. In this example there is a token 
ring connection being used, so the Netware device driver required for that 
adapter will be loaded. If the adapter being used is a different one, replace the 
network drivers listed with those required to support the appropriate type of 
connection. 



The following chart lists the required files and where they are to be copied from. 



Table 7 . Token-Ring Netware Required Files . These fifes should be copied from the 
directory listed on the 0 FROM 0 section to the drive fisted in the "TO" section listed 
using the COPY command. This fist is only valid for a token-ring network . 


Copy from 


To 


Machine 


File Path / name 


Machine 


Drive 


SYSCON terminal 


C:\NETWARE\NWCONFIG.DLL 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NE7WARE\IPXCALLS.DLL 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWCALLS.DLL 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\LSLSYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\TOKEN.SYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\ROUTESYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWDAEMON.EXE 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWREO.SYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NWIFS.IFS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\IPX.SYS 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NET.MSG 


SYSCON terminal 


A:\ 


SYSCON terminal 


C:\NETWARE\NETH.MSG 


SYSCON terminal 


A:\ 



The STARTRFI.CMD is required in the LT disk and should resemble the following. 
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: START 

IF EXIST L:\0S2\L0GIN.EXE GOTO EXIT 
GOTO START 
: EXIT 
L: 

CD\0S2 

LOGIN 

MAP Z : =LANMAN\SYS : PUBLIC\0S2\0S2 IMG 
MAP N : =LANMAN\SYS : PUBLIC\0S2\NWFI LES 
MAP R: =LANMAN\SYS: Pl)BLIC\0S2\REXX 
DETACH R:\REXINIT 

PAUSE 

CALL Z:\DISKPREP.CMD (optional for disk preparation) 

IF ERRORLEVEL 4 GOTO END 
A: 

Z:\RSPINST Z:\0S2SE20.RSP 
:END 

©ECHO OFF 

ECHO "Partitioning not done. Cannot complete installation" 



Figure 45. STARTRFI.CMD Contents for an Advanced Installation 

In the above STARTRFI.CMD program the user is prompted for the login ID. The 
server should have already been set up to recognize these user ID's. 

— Important! 

To be able to individually customize the client machines during the 
installation process and/or collect the installation log file, the individual user 
ID's must have already been created on the server and used here to login to 
the network. 



Also in the response file used (OS2SE20 in this case) a keyword must be added 
as shown here: 

UserExit= N:\NWINST.CMD 

The USEREXIT keyword is used to start the NWINST.CMD program upon the 
completion of the response file processing. For a complete description of the 
keywords supported please refer to Appendix A, “Response File Keyword 
Reference, Samples And Details” on page 117. 
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A1 ternateAdapter=0 

BaseFi1eSystem=2 

CDROM=0 

CountryCode=001 

CountryKeyboard=US 

Defau1tPrinter=91 

Di agnosticAids=l 

DisplayAdapter=0 

WindowedWIN-OS/2=0 

Documentati on=l 

DOSEnvi ronment=l 

WIN-OS/2Desktop=0 

DPMI=1 

ExitOnError=0 

Fonts=l 

FormatPartition=l 
Incl ude»X : \ INDI V . RSP 

Mi grateConf i gFi 1 es=0 

MoreBi tmaps=0 

Mouse=l 

MousePort=0 

Opti onal Fi 1 eSystem=l 

Opti onal SystemUti 1 iti es=l 

PrimaryCodePage=l 

PrinterPort=l 

ProcessEnvi ronment=l 

Progress I ndi cati on=l 

RebootRequi red=0 

REXX=1 

Seri al Devi ceSupport=l 
TargetDrive=C: 

ToolsAndGames=l 

USER EXIT=N: \NWINST.CMD 

Figure 46. OS2SE20.RSP File Contents for an Advanced Installation. Notice the 
keywords that have been highlighted. This example has been shortened to show only the 
keywords used. 

There are some CONFIG.SYS file considerations also. They are: 

• Change the OS2_SHELL statement to 

SET OS2_SHELL=CMD.EXE /K A:\STARTRFI.CMD 

• Add R:\ to the Dpath and Libpath statement 

• Add Z:\Disk_1 to the Path statement 

• Add the required Netware device statements 

• Add the SOURCEPATH=Z: statement. 

A copy of the CONFIG.SYS used for this example follows. 



\ 
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buffers=32 

i opl =yes 

memman=noswap 

protshell= sysinstl.exe 

SET 0S2_SHELL-CHD.EXE /K A:\STARTRFI.CMD 

protecton1y=yes 

LIBPATH°. ;\;\0S2\DLL;R:\; 

ifs=hpfs.ifs /c:64 /autochecktc 

pauseonerror=no 

codepage=850 

devi nf o=kbd , us , keyboard . dcp 

devi n f o=scr , ega , vtbl 850 . dcp 

device=\dos.sys 

device=\mouse.sys 

rem devi ce=c :\i bml ds\1 ds . sys 

SET PATH-\}\OS2\SYSTEHj\0S2\IHSTALL}Z:\O1sk_l5 

SET DPATH'A ; \0S2\SYSTEH; \0S2\INSTALL; R: \ ; 

set keys=on 

basedev=pri nt01 . sys 

basedev=i bmlf 1 py . add 

basedev=i bmls506.add 

basedev=i bm2f 1 py . add 

basedev=i btn2adsk. add 

basedev=ibm2scsi .add 

basedev=i bmi ntl3. i 13 

basedev=os2dasd . dmd 

SET SOURCEPATH=Z:\ 

REH — - NetWare Requester statements BE6IN — 

DEVI CE s A : \ LSL . SYS 

REH — Network Adapter Card — - 

DEVICES: \T0KEN.SYS 

DEVICES : \R0UTE . SYS 

DEVICE=A:\IPX.SYS 

DEVICE-A:\NWREQ.SYS 

IFS=A:\NWIFS.IFS 

RUN-At\NWDAEKON.EXE 

REH — NetWare Requester statements END — 

Figure 47. Example of CONFIG.SYS on the LT Diskette. The lines particular to the 
installation are shown highlighted. 

There is a listing of the LT disk shown on Figure 39 on page 80. The directory 
listing is the same for both the Basic and Advanced installation LT diskettes 
except for the LOOP.CMD program which is only required for a basic 
dialog-driven installation. 
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7.4.4 Advanced Installation of OS/2 V2.0 on the Client Machine. 

This section will describe the procedures to be followed to perform the actual 
installation of OS/2 V2.0 and the Novell Netware requester code on the client 
machines. It is assumed that there is a physical token ring network connection 
on the client machine and that the server and LT preparations have been 
completed as described in 7.4.2, “Novell Netware Advanced Installation Server 
Preparation” on page 84 and 7.4.3, “Preparation of the Novell LT Diskettes” on 
page 89. 

This installation method of OS/2 V2.0 assumes that the client machine is either: 

• A new Personal Computer that has not been partitioned or formatted yet in 
which case the disk may be partitioned during the install process using a 
fixed disk partitioning program such as in Appendix F, “Automating Fixed 
Disk Partitioning" on page 159. 

or 

• An existing Personal Computer which has one or multiple partitions on it and 
the partition which is to have OS/2 V2.0 installed on it has been set as 
Installable (for Boot Manager) or Active. 

Should there be programs to be migrated from a DOS or Windows environment 
please refer to 3.3, “Upgrading DOS Systems to OS/2 V2.0” on page 10. 

To begin the installation process: 

• Place the OS/2 V2.0 Installation disk in the A: drive and power on the client 
machine. 

• When prompted, place the LT disk in A: and press Enter. 

This will begin the installation process. 

Once the CONFIG.SYS file has finished being processed it will run the 
STARTRFI.CMD program that was entered on the OS2_SHELL statement. The 
STARTRFI.CMD file may be seen in Figure 45 on page 91. 

The following explains the steps that the STARTRFI.CMD program goes through: 

• The program connects to the L: drive (on the server) 

• The user is prompted for their login 

When logging in: 

Be sure to use the individual user ID for this workstation. Any client machine 
individualization and log file collection will be done using the user ID home 
directory that was created on the server, during the user ID creation. 

• The Z: drive is mapped to the SYS:PUBLIC\OS2\OS2IMG directory on the 
server 

• The N: drive is mapped to the SYS:PUBLIC\OS2\NWFILES directory on the 
server. 

• The R: drive is mapped to the SYS:PUBLIC\OS2\REXX directory on the 
server. 

• The REXINIT program is started. 

• The DISKPREP.CMD program is run if it was used. 
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• The RSPINST program is started, which reads the OS2SE20.RSP file for the 
system configuration input. 

• The OS/2 images are read from the Z: drive. 

The diagram in Figure 48 shows the required mapping as well as the client 
environment for an advanced installation. 




Figure 48. Client Environment for an Advanced Installation 

| USEFUL TIP 

The progress of the installation may also be monitored from the Novell 
Netware server by using the MONITOR function and viewing the Open Files 
for this user ID's Connection. 



At the end of the response file processing, the USEREXIT keyword is processed, 
which in turn processes the NWINST.CMD file that is on the N: drive. The 
contents of the NWINST.CMD file can be seen in Figure 42 on page 86. The 
NWINST program will perform the following: 

• Add (NWDrv):\NETWARE to the PATH, DPATH and LIB PATH statements of 
the CONFIG.SYS, where (NWDrv) was the target drive of the NETWARE 
installation on the client machine. 

• Adds the required NETWARE device driver statements to the CONFIG.SYS. 

• Creates a (NWDrv):\NETWARE directory on the client machine. 

• Copies all the files from N: drive to (NWDrv):\NETWARE. 
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• Copies the OS/2 V2.0 installation log file to the user's home directory on the 
server. 

When the process is complete a panel will be displayed stating that the 
installation has completed. Remove the diskette from the A: drive and reboot the 
workstation. When it restarts, there will be: 

• A completely customized operational version of OS/2 V2.0 on the client 
machine. 

• A completely operational Novell Netware requester on the client machine. 

• A copy of the OS/2 V2.0 installation log file on the user's home directory on 
the server. 



7.5 Disketteless Upgrade of OS/2 1.3 for Novell workstations 

This section will describe one method of upgrading OS/2 V1.3 workstations to 
OS/2 V2.0. This method does not require any diskettes to be used at the client 
machine to complete the process. It is a "pull" method, which means that the 
upgrade process must be initiated at the client machine. 

7.5.1 Assumptions 

It is assumed that the client machine is: 

• Operating on OS/2 Version 1.3. 

• Has the OS/2 Netware requester code installed in the NETWARE directory. 

• Will keep the same partitions as used now. 

• Will have the new Novell Netware requester code installed on it during the 
upgrade process. 

• The server has been prepared as described in 7.4.2, "Novell Netware 
Advanced Installation Server Preparation” on page 84. 

• The drive assignments made during the server setup as explained in 7.4.2, 
“Novell Netware Advanced Installation Server Preparation” on page 84 will 
be used in this example. 

• The server name used in the example is "LANMAN". 

• The user ID used in the example is "RichardC". 

Should the client machine not have fit any of the above criteria then it is 
recommended that the OS/2 V2.0 installation be performed as described in 
Chapter 7, “Novell Netware Client/Server Solution” on page 65. 

Time Saver 

All the batch files listed in this section may be found on the Sample Code 
Disk 
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7.5.2 Overview of Disketteless Upgrade Using Novell Netware 

The following list Is an overview of upgrade process: 

• The administrator prepares the server 

• The user runs the upgrade program 

• The process creates a "seed" OS/2 V2.0 system on the client machine and 
modifies the client machine CONFIG.SYS file 

• The client machine is rebooted 

• The client machine starts and runs the SEINST program 

• OS/2 V2.0 is installed remotely and the client machine is rebooted with the 
new operating system installed and the old applications intact. 



7.5.3 Novell Server Preparation for a Disketteless Upgrade 

The upgrade process will require the use of a couple of the CID utilities that 
must be unpacked using the procedure explained in 4.1, “The CID File” on 
page 17. The two programs required are: 

• SEMAINT 
and 

• SEINST 

Both the SEMAINT and SEINST programs must be installed on the 
SYS:PUBLIC\OS2\OS2IMG directory of the server. 

Unpack the SEMAINT and SEINST onto the SYS:PUBLIC\OS2\OS2IMG directory 
of the server. 

Add the following statement to the login script for each of the user ID's that are 
to upgraded using this process. This is assuming that the Netware default home 
directory is being used. If it is not simply place the actual home directory for the 
user in the MAP statement shown. 

MAP X: = LANMAN\SYS:"userid" 

There are several batch files which need exist on the N: drive. These may be 
created using an ASCII text editor or they may be copied from the Sample Code 
Disk. The following figures contain the contents of the files and explain where 
they should be placed. 

Copy the following batch file called NNUPGRFI.CMD to the N: drive. 
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: START 

IF EXIST L:\OS2\LOGIN.EXE GOTO EXIT 
GOTO START 
: EXIT 
L: 

CD \0S2 
LOGIN 

HAP Z : =LANMAN\SYS: PUBLIC\0S2\0S2 IMG 
MAP N : =LANMAN\SYS : PUBLI C\0S2\NWFI LES 
MAP R : =LANMAN\S YS : PUBLI C\0S2\REXX 
DETACH R:\REXINIT 
set REMOTE_INSTALL_STATE=0 

Z:\SEINST /B:C: /T:C:\MAINT /R:Z:\0S213UPG.RSP /S:Z:\ /L1:C:\0S213UPG.L0G 



Figure 49. Example of NNUPGRFI.CMD File. This batch file is called by the seed system 
CONFIG.SYS to initiate the OS/2 V2.0 download, when the client machine is booted from 
the seed system. 

Copy the following program called NNUPG13.CMD to the N: drive. 



/* REXX program to upgrade a 1.3 workstation to Version 2.0 */ 

/* */ 

Address cmd 
'Gecho off 1 

CltDrv 'C: ' /* Sets OS/2 Drive */ 

/* Next line will create the seed system on the workstation */ 

/* in a directory called MAINT. It will be created by the */ 

/* SEMAINT program on the drive specified above as CltDrv. */ 

■Z:\SEMAINT /S:Z:\/T: • \ jCl tDrv! ! '\MAINT/B: ' j jCltDrv' /LI: • | jCltDrv! ! 1 \HAINT.LOG' 
'Copy N:\NNUPGRFI.CMD 'CltDrv! \ '\HAINT' 

/* The following line copies the Version 2 Netware code to the */ 

/* client machine, to connect to the server from the seed system */ 



'HD 'CltDrv!! '\MAINT\NETWARE' 

'Copy N:\NWC0NF1G.DLL 'CltDrv! ! '\MA1NT\NETWARE' 

' Copy N:\IPXCALLS .DLL 'CltDrv!!' \MAINT\NETWARE ' 

'Copy N:\NWCALLS.DLL 'CltDrv! ! '\HAINT\NETWARE' 

'Copy N:\LSL.SYS 'CltDrv! ! '\HAINT\NETWARE' 

'Copy N:\TOKEN.SYS 'CltDrv! ! '\HAINT\NETWARE' 

'Copy N:\ROUTE.SYS 'CltDrvJ ! ' \MAINT\NETWARE ' 

'Copy N:\NWDAEMON.EXE 'CltDrv! ! ' \MAINT\NETWARE * 

'Copy N:\NWREQ.SYS 'CltDrv! ! '\HAINT\NETWAR£' 

'Copy N:\NWIFS.IFS 'CltDrv! ! '\MAINT\NETWARE' 

'Copy N:\1PX.SYS 'CltDrvJ ! ' \MAINT\NETWARE ' 

'Copy N:\NET.HSG 'CltDrvJ ! '\HAINT\NETWARE' 

'Copy N:\NETH.HSG 'CltDrv! ! '\MAINT\NETWARE* 

/* Change the PATH, DPATH and LIBPATH statements in the seed */ 
/* CONFIG.SYS file, 
ol dcs-Cl tDrv ! ! ' \C0NFIG. SYS ' 
newcs=CltDrv! ! '\CONFIG.NEW 

Do while lines(oldcs) /* Do until end of file */ 

line-linein(oldcs) /* Read In a line */ 

1 1 ne-translate (line) /* Convert to UPPERCASE */ 



Figure 50 (Part 1 of 2). Contents of NNUPG13.CMD File 
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end 

/* 



If pos ( 'PROTSHELL' , line) <> 0 then /* If PROTSHELL is in line */ 
do 

1 i ne° 1 PROTSHELL 3 1 Cl tDrv 1 \MAINT\CMD. EXE /K' CltDrv| | ' \MAINT\NNUPGRF I . CMD ‘ 
end 

If pos (TIBPATH', line) <> 0 then /* If LIBPATH is on line */ 
do 

1 incline ! i '; ' | ! Cl tDrv! ! '\MAINT\NETWARE;R:\; 1 
end 

If pos ( 'SET PATH', line) <> 0 then /* If SET PATH is on line */ 
do 

line c linei i 1 ! J Cl tDrv [ \ '\MAINT\NETWARE; ' 
end 

If pos ('SET DPATH',line) <> 0 then /* If SET OPATH is on line */ 
do 

1 ine**l inej ! | J Cl tDrv [ \ '\MAINT\NETWARE;R:\; ' 
end 

Call lineout newcs,line /* Write line out to Config.new */ 



Add the device statements to the CONFIG. NEW file 



V 



/* The following lines add the required device statements to the 
/* Config.sys for the NETWARE network. 

/* Includes TOKEN RING drivers only 
call lineout newcs,' ' 
call lineout newcs REM' 

call lineout newcs, 'REM Beginning of Netware device statements' 
call lineout newcs,'REM' 



' \MAINT\NETWARE\LSL. SYS ' 

' \MAI NT\NETWARE\ TOKEN . SYS ’ 
' \MAINT\NETWARE\ROUTE. SYS ’ 
'\MAINT\NETWARE\IPX.SYS ' 

' \MAINT\NETWARE\NWREQ. SYS ' 



V 

V 

V 



call lineout newcs, 'DEVICE- 'Cl tDrv J 
call lineout newcs, ' DEVICE* * Cl tDrv { 
call lineout newcs, ‘DEVICE 11 'Cl tDrv! 
call lineout newcs, 'DEVICE 3 'Cl tDrv| 
call lineout newcs, ' DEVICE* 8 'Cl tDrv ! 

call lineout newcs, ' I FS= ' Cl tDrv { ! '\MAINT\NETWARE\NWIFS. IFS' 
call lineout newcs, ' RUN= ' Cl tDrv || '\MAINT\NETWARE\NWDAEMON.EXE' 
call lineout newcs, 'REM' 

call lineout newcs, 'REM - NetWare Requester statements END — ' 
call lineout newcs,' ' 

/* V 

/* Close the files */ 

/* V 

Call stream oldcs, 'c ', 'close' 

Call stream newcs, 'c', 'close' 

/* V 

/* Copy the new CONFIG.SYS into place */ 

'Copy ' | | newcs! ! ' ' \ \ oldcs 
'Erase '!!newcs 

/* V 

/a******************************************************************/ 
/* Write banner to screen */ 

/*******************************************************************/ 
say '<-[0;7m'; 
do; 

'@cls'; 
say ' [8; 1H ' ; 



say 

say 

say 

say 

say 

say 

say 



left ('=' ,76, '=') j! Y; 
left (' ',76) i ! 'll'; 

center(Upgrade preparation is complete, 76) !! ' ; 

center(please shutdown the system, 76) || ' || ' ; 
center(from the Desktop Manager and reboot., 76) !! '[| 
leftC ‘,76) !j*h 
left(’ =, ,76, '=') !! ,J J‘i 



end; 

do forever 
nop 
end 



Figure SO (Part 2 of 2). Contents of NNUPG13.CMD Fife . This file is used to upgrade an 
OS/2 VI. 3 client machine to OS/2 V2.0 and is called by the user from the client machine 
to start the upgrade process. 



Chapter 7. Novell Netware Client/server Solution 99 




The following is an example of the file NNUPG.CMD file that is called as a 
UserExit from the OS213UPG.RSP file. 



/* REXX procedure to complete Netware Installation and */ 

/* copy UPGRADE logs to server. Called as a USEREXIT */ 

/* from the 0S213UPG.RSP response file. V 

/* V 

/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/ 

/* Write banner to screen V 

/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/ 

say '«-[0;7ta'; 
do; 

'Gels'; 
say ’«*[8;1H’; 



say 

say 

say 

say 

say 

say 



left('=',76, '=') j! Y-, 
leftC *,76) H-S’i 
center (Copying Netware files, 76) || 
center(frem the server, 76) || ‘|'j 
leftC *.76) I! 'll’! 
left(‘=',76, '=’) |! 'I'i 



end; 

address and 
'Gecho off 1 

'COPY C:\NETWARE >nul 2>C: \MAINT.LOG' 

/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/ 

f* Write banner to screen V 

^AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA j 

say * ^ [0 ; 7m ' ; 
do; 

'Gels'; 
say '♦'[8;lH'j 



say 

say 

say 

say 

say 

say 



left('=\76,'=') !! 'ii'; 
leftC ‘.76) U'b 

center(Copying installation logs»76) jj 
center(to the server,76) || ' || ' ; 
leftC ',76) il'il'i 
left('=',76, '=') I! -I'i 



end; 

'copy C:\OS213UPG.LOG X:\ >nu1 2>C:\0S213UPG.L0G' 
'copy C:\HAINT.LOG X:\ >nul 2>C: \HAINT.LOG' 



Figure 51. Example of the NNUPG.CMD File Contents. This is called from the 
OS213UPG.RSP file and is used to copy the Netware files to the client machine and the 
installation log files to the users home directory on the server. 



The following OS213UPG.RSP response file is called by the SEINST.EXE file to 
remotely install OS/2 V2.0. It must be created or copied from the Sample Code 
Disk to the Z: drive. 
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A1 ternateAdapter=0 

BaseFi1eSystem=2 

CDROM=0 

CountryCode=001 

CountryKeyboard=US 

DefaultPrinter=91 

DiagnosticAids=l 

DisplayAdapter=0 

Wi ndowedWIN-OS/2=0 

Documentation^ 

DOSEnvironment=l 

WIN-OS/2Desktop=0 

DPMI=1 

Exi tOnError=0 
Fonts=l 

F ortnat Part it1on=0 
Include=X:\INDIV.R$P 
HigrateConf IgFIl es=l 

MoreBi tmaps=0 

House=l 

MousePort=0 

Opti onal Fi 1 eSystem=l 

Opti onal SystemUti 1 i t i es=l 

PrimaryCodePage=l 

Pri nterPort=l 

ProcessEnvi ronment=l 

Progress Indi cati on=l 

RebootRequi red=0 

REXX=1 

Seri al Devi ceSupport=l 

Target Dr ive=C: 

Tool sAndGames=l 
USEREXIT=N : \ NNU PG . CHD 



Figure 52. Example of the OS213UPG.RSP File. Notice the keywords which have been 
highlighted. The USEREXIT keyword calls the NNUPG.CMD file that has been created on 
the N: drive and shown in Figure 51. 



7.5.4 Starting the Upgrade 

Before starting the upgrade process make sure the following drive mappings 

exist on the client machine: 

• Z: = LANMAN\SYS:PUBLIC\OS2\OS2IMG 

• N: = LANMAN\SYS:PUBLIC\OS2\NWFILES. 

Once the above has been done, simply access the N: drive and type NNUPG13. 

This will begin the upgrade process by doing the following to the client machine: 

Note: The following procedure may be followed on the diagram illustrated in 

Figure 53 on page 103. 

• Starts SEMAINT and creates a "seed" OS2 system on the \MAINT 
subdirectory (the directory will be created). 

• Modifies the seed CONFIG.SYS to add the necessary path and device driver 
statements. This will allow the seed OS/2 V2.0 system to connect to the 
server when it reboots from the \MAINT directory. 
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• Copies the NNUPGRFI.CMD file to the \MAINT subdirectory of the client 
drive. 

• Downloads the necessary OS/2 V2.0 Netware device drivers to the 
C:\MAINT\NETWARE directory, to enable the seed system to connect to the 
server and modifies the CONFIG.SYS to point to the \MAINT subdirectory. 

When all the above is complete the client machine will need to be rebooted. 

When the system restarts: 

• It does so from the seed OS2 system and runs the NNUPGRFI.CMD file as 
per the PROTSHELL statement in the seed CONFIG.SYS file. 

• The seed OS2 system will connect to the Novell Netware server and perform 
a login. The user ID is prompted for on the screen so any customization of 
the client machine that is contained in the INDIV.RSP file of the user's home 
directory may be performed. The installation logs will also be copied to the 
user's home directory on the server. Customization is explained in 7.4.2, 
"Novell Netware Advanced Installation Server Preparation” on page 84. 

• The Z: drive is mapped to the LANMAN\SYS:PUBLIC\OS2\OS2IMG directory 
to access the OS/2 V2.0 images and the CID utilities. 

• The N: drive is mapped to the LANMAN\SYS:PUBLIC\OS2\NWFILES directory 
to access the NNUPGRFI.CMD, NNUPG13.CMD as well as the new Novell 
Netware requester files that will be downloaded to the client machine. 

• The X: drive is mapped to the LANMAN\SYS:RichardC directory, as per the 
users login script, which should be the home directory for the user. 

• The R: drive is mapped to the LANMAN\SYS:PUBLIC\OS2\REXX directory on 
the server to access the REXINIT.EXE file which is required during the batch 
file processing of the UserExit. 

• The SEINST environment is set. 

• SEINST is run and the OS/2 V2.0 code is installed on the target drive 
specified in the response file OS213UPG.RSP as shown in Figure 52 on 
page 101. 

• The INDIV.RSP file from the users home directory is called by the ONLUDE 
Keyword of the OS213UPG.RSP response file. 

Caution 

Make sure that the client machine hard file is not formatted during the 
installation process. The FormatPartition keyword in the response file 
should be equal to 0. 



• The N:\NNUPG.CMD is called by the UserExit in OS213UPG.RSP response 
file. 

• NNUPG.CMD copies the Novell Netware requester files to the client machine. 

• The log files are copied from the client machine to the user's home directory 
on the server. 

When the above process is complete the machine must be rebooted. When it 
restarts it does so with: 

• A completely operational version of OS/2 V2.0 on it 

• The OS/2 V2.0 Novell Netware requester code installed on it 
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The log files copied to the server. 



Note that the migration process will REM all DEVICE, RUN, and IFS statements 
from the OS/2 VI. 3 CONFIG.SYS. The user must manually remove the REM from 
the desired statements, or the administrator could design a REXX procedure to 
automate the task. 

The following diagram shows the chain of events that the upgrade process goes 
through to upgrade from OS/2 VI. 3 to OS/2 V2.0 



Client 

Machine 




Userid "RichardC” 

N:\NNUPG13.CMD 



C:\MAINT 



CONF1G.SYS 

C:\MA1NT 



\MAINT\NETWARE 



CONFIG.SYS 

I 

REBOOT 

i 

RECONNECT - 



C:\MAiNT\NNUPGRFI.CMD 

— LOGIN 

— MAP 2: = 

— MAP N: = 

— MAP X: = 

— MAP R: = 



OS/2 V 2.0 



X:\INDIV.RSP 



C:\NETWARE\V 



\OS2MNSTALLMNST ALL. LOG 



Netware Server 



■1 


m 


■ 


=d 


■ 




I 






H 


1 



server "LANMAN" 



creates 



- copied to 



downloaded to 
■ modifies 



■ calls 



downloads 
include 



downloads - 



- copied to - 



SEMA1NT - 
SEMAJNT • 



- N:\NNUPGRFI.CMD - 
NETWARE DRIVERS - 



SERVER 



RichardC 

SYS:PUBLIC\OS2\OS2IMG 
SYS: PUBLIC\OS2\NWFI LES 
SYS: RichardC 
SYS:PUBLICV0S2\REXX 

SEINST 



OS213UPG.RSP ' 



OS213UPG.RSP - 



0S213UPG.RSP 
UserExit N:\NNUPG 



X:\INSTALL.LOG 



Figure 53. Flow of Events During the Upgrade Process 
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Chapter 8. Alternative Methods to Install OS/2 V2.0 Remotely 



This chapter will describe the attended remote dialog-driven installation of OS/2 
V2.0 using a redirected drive and the regular installation program SYSINST2.EXE. 



8.1 Attended Dialog-Driven Installation 

The attended dialog-driven installation of OS/2 V2.0 could be used as an 
alternative method to install if workstations are connected to a LAN. 

This type of installation utilizes the original OS/2 V2.0 installation program 
(SYSINST2.EXE), which requires a user dialog and then installs OS/2 V2.0. 

The major difference between a regular installation of OS/2 V2.0 and this 
attended dialog-driven installation is the fact that after the first two diskettes 
("Installation" and "LT diskette") the installation proceeds without asking the user 
to insert any more diskettes into drive A:. 

Instead the installation program utilizes the redirected drive and automatically 
continues reading the diskette images from there. 

The process will also copy all non system files from the root directory of the 
diskette to the root directory of the TargetDrive. 

After installing a “first stage” system the system will request a reboot. (Don't 
forget to remove the "LT diskette" from drive A:.) 

Upon reboot the system uses a derived version of the CONFIG.SYS file from 
drive A:. This makes it possible to reconnect to the redirected drive. See 6.3.3, 
“Preparation of the NFS Client LT Diskette” on page 40 or 7.3.3, “Preparation of 
the Novell LT Diskettes” on page 72 for special treatment in these environments. 

The system then initializes a special Presentation Manager’ shell program that 
completes the installation. In the final stage the system requests to install 
printers, which are then also installed from the redirected drive. 

8.1.1 Prepare Dialog-Driven Installation Diskettes 

The following steps are needed, to be able to perform a dialog-driven 
installation: 

• Set up a server 

Depending on the environment follow the informations provided in 7.3.1, 
“Novell Netware Basic Installation Server Preparation” on page 68 or 6.3.1, 
“NFS Server Preparation for Basic Scenario” on page 38 to prepare the 
server. 

• Install the CID package 

See 4.1, “The CID File” on page 17 for further details. 

• Run the SEIMAGE procedure to create the image directory on the server 
See 4.1.1, “SEIMAGE” on page 18 for further details. 

• Run the SEDISK procedure to create the basic installation diskettes 
See 4.1.2, “SEDISK” on page 19 for further details. 
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• Modify CONFIG.SYS on the "LT diskette". 

Add and modify the statement in the CONFIG.SYS to reflect the correct 
transport environment. {See 7.3.3, “Preparation of the Novell LT Diskettes" 
on page 72 or 6.3.3, “Preparation of the NFS Client LT Diskette" on page 40 
for details.) 

• Change the OS2_SHELL statement on CONFIG.SYS. 

The OS2_SHELL statement should read as follows: 

SET 0S2_SHELL=Z s\DISK_l\SYSINST2.EXE Z:\ 

assuming disk Z: is an accessible redirected drive. 

After these preparations the two diskettes are prepared for dialog-driven 
installation. 

8.1.2 Perform a Dialog-Driven Installation 

A dialog-driven installation follows this procedure: 

• Insert the diskette labelled "Install" into drive A:. 

• Boot the workstation. 

• Upon request insert the LT diskette into drive A: and press Enter. 

• Follow all dialogs. 

After some actions and copying the system eventually will request a reboot. 

• Remove the LT diskette from drive A: and follow the information on the 
screen. After reboot the system will continue with dialogs and copying files. 

Finally the system will request a second reboot. 

• Reboot the system a second time. 

Assuming all questions were answered correctly the system should now 
start with the regular PM shell, build its new desktop and run properly. 



8.2 The Use of a Portable Installation Server 

Independent of any host connection, the following section could be of interest. 
Although it needs operator intervention on all levels (server, client, moving of 
material) it is a fast way to get different larger LAN networks converted to OS/2 
V2.0. 

Usually the server itself must be installed manually, which, in the case of many 
physical LANs, is a very time-consuming activity. But still, this "attended" version 
can be sped up by following the procedures below. 

Instead of manually installing each server on each LAN network before the 
duplication process is started, an "injection"-PS/2 is created (for example a P70). 
The term "injection" is used because this workstation is added (injected) to the 
LAN, started and thereby becomes a new workstation with server capabilities. 
This server can be accessed by any workstation on the LAN, by simply starting 
any of these workstations with the two remote install diskettes. 

This workstation has all the required system software installed readily available 
as image files that can be accessed by any workstation on the LAN. 



106 OS/2 V2.0 Remote Installation 




Depending on what installation procedure is going to be followed as mentioned 
in the previous chapters, some customization might be needed before 
installation can be initiated. 

This injection server now is fully prepared for all networks and can be distributed 
throughout the site for installation purposes and hooked into any LAN. 



8.3 CD-ROM 



IBM has introduced the PS/2’ Ultimedia’ Model 57-SLC, which allows a customer 
to install their choice of operating systems: 

• DOS 5.0 

• Windows 3.0 with Multimedia Extensions 

• OS/2 2.0 from the existing CD-ROM drive. 

A 2.88 megabyte installation diskette loads OS/2 2.0 and the CD-ROM device 
drivers. OS/2 2.0 is installed by using a response file that has been predefined at 
the manufacturing plant. Because customers may purchase the display 
separately, they will be required to modify the response file to enable touch 
screen support for an 8516 display. 

IBM intends to deliver OS/2 2.0 on CD-ROM as a separate product to provide fast 
and convenient installation from IBM and non-IBM CD-ROM drives. 
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Chapter 9. OS/2 V2.0 System Maintenance 



This chapter describes how the Corrective Service Facility (CSF) is used for the 
distribution of Corrective Service Diskettes (CSD) for OS/2 V2.0 using redirected 
I/O from a server onto client workstations. 



9.1 Introduction to Corrective Service Facility 

The purpose of CSF is to apply CSDs for the OS/2 V2.0 operating system. This 
section shows how to use CSF to service OS/2 V2.0. 




Each product under OS/2 V2.0, namely the base operating system, the Extended 
Services and the LAN Services, that have to be serviced by a CSD has a 
"syslevel" file. This syslevel file is installed with each product. For example the 
OS/2 Base Operating System has a syslevel file named SYSLEVEL.OS2 that is 
installed in the OS2MNSTALL directory. When a CSD is installed for a product, 
the corresponding syslevel files are updated to reflect the new CSD "syslevel". 
The CSF uses these syslevel files to identify the products on the system and to 
verify that the products will not be "downleveled" by installing the CSD. 

When the CSF installs a CSD for a product, it must determine what directories 
are associated with the product. For each of the products serviced by a CSD 
there is a set of default directories. These are the directories that would 
normally be serviced for this product. A CSD for the OS/2 base operating 
system services the root directory, the OS/2 directory, and all subdirectories of 
the OS2 directory. 

The requirements of CSF to install OS/2 V2.0 maintenance on an enterprise's 
workstations is similar to that required for the installation process. CSD diskette 
images reside on a server workstation available for client workstations to attach 
to and install service from. CSF uses a response file to determine maintenance 
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installation characteristics, but must not be confused with the response file used 
for the installation of OS/2 V2.0 using a redirected drive. 

The files needed for CSF, namely FS1.EXE, FSERVICE.EXE and the CSF response 
file, can be found on the second disk of the CSD diskettes. The function of these 
files will be described below. 

9.1 .1.1 FS1.EXE and FSERVICE.EXE 

CSF provides two files, namely FS1.EXE and FSERVICE.EXE, for the distribution of 
CSDs. As mentioned above these files are provided on the second CSD diskette. 
Each CSD has two boot diskettes {OS/2 Corrective Service Diskette 1 and 2). 
Diskette 2 contains the CONFIG.SYS file, which uses the FS1.EXE and 
FSERVICE.EXE programs. FS1 displays the startup screen and provides the 
required processing environment. FSERVICE uses a response file as input to the 
process of installing maintenance. 

The following statements must be included in the CONFIG.SYS on diskette 2: 
PROTSHELL=<pat h>FSl . EXE 

SET 0S2_SHELL=<path>FSERVICE.EXE <parameters> 

The following command line parameters are valid for FSERVICE.EXE: 

/R: Response file 

This specifies the fully qualified path and name of the response file. 
This parameter is mandatory. There is a default response file that 
can be located on the second CSD diskette called RESPONSE. FIL. 
This default response file will service all products on the system. 

No blank spaces are allowed between the colon and the path of the 
response file 

/S: Source directory 

This parameter is optional. It specifies the base directory of the 
CSD image. The CSD image must have been prepared prior to 
service. This parameter will override the :SOURCEPATH tag in the 
response file if the tag exists. No blank spaces are allowed 
between the colon and the parameters specified for the source 
directory. 

/LI: Log file 

This parameter is optional. It specifies the fully qualified path and 
the name of the log file. This parameter overrides the :LOGFILE tag 
in the response file, if the tag exists. If no log file is specified 
OS2\INSTALL\SERVICE.LOG will be used. No blank spaces are 
allowed between the colon and the parameters specified for the log 
file. 

There are advantages in ensuring these programs reside on the server rather 
than on each client's LT diskette: 

• All LT diskettes remain valid given an operating system upgrade 

• Space saved on each LT diskette. 

In order for clients to access these programs from the server the PROTSHELL 
and the SET OS2_SHELL statement in CONFIG.SYS on the clients LT diskette 
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need to reflect the fact that they reside on a redirected drive, and that the client 
has access to this drive. 

9.1 .1 .2 The CSF Response File 

The response file required by CSF should not be confused with the response file 
used by the installation process. This response file is a flat ASCII file consisting 
of tags and parameters. The asterisk in the first column marks a comment line. 

A default response file called RESPONSE.FIL is provided and resides on the 
second CSD diskette. It must be kept in mind that the tags :SERVICE, :BACKOUT 
and :COMMIT are mutually exclusive, therefore allowing only one service to be 
started in a single response file. The following list shows the valid response file 
tags and their purposes: 

• SERVICE 

Indicates this to be a service. In other words the rSERVICE tag will install the 
necessary CSDs to the operating system. Only one of :SERVICE, :BACKOUT, 
and :COMMIT are valid in a single response file. If :SERVICE is provided at 
least one :DIRLIST must be specified as described below. If the :ARCHIVE 
tag is specified in the response file, the service will be enabled for backout. 
:ARCHIVE can only be used if there is enough space left on the hard disk. If 
it is not specified the client workstation can not be backed out. 

• :BACKOUT< syslevel 1 > <syslevel 2> ... 

Indicates this to be a service backout. If the CSDs have been applied to a 
workstation a user has the ability to back out of the CSF if required to do so. 
The system will return to the previous level of the operating system. 

The <syslevel> parameters specify which products should be backed out. 
Only the syslevel files listed will be backed out. The syslevel file is only 
eligible for backout if the product was serviced with the backout feature 
enabled. For the backout feature to be enabled the tag :ARCHIVE must be 
used, as described in the :ARCHIVE tag below. 

• :ARCHIVE < archive path > 

Indicates the archive directory for backout-enabled service. In other words if 
a user wants to apply the CSDs and be able to back out at any time, the 
:ARCHIVE tag must be specified. This tag is only used if the :SERVICE tag is 
specified. This tag will archive all the files that will be replaced by the CSF. 
The :ARCHIVE tag will check if there is enough space on the target disk 
before the CSD is applied. If the :BACKOUT tag is then used the previous 
files will be retrieved, leaving the system in its original state. 

The path specified on the :ARCHIVE tag must be on a local, non-removable 
hard drive. If the < archive path> is not specified, the local hard drive with 
the most space will be used to archive the files. 

• :COMMIT < syslevel 1> < syslevel 2 > ... 

Indicates this to be a service commit. The commit tag allows a user who 
has applied the CSF with the backout feature enabled to remove the archived 
files from the system, when they are no longer needed. 

Only the products specified by the syslevel specifiers will be committed. If 
no syslevel specifiers are provided, all eligible syslevel files will be 
committed. 

• :DIRLIST < syslevel 1> < syslevel 2 > ... 
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Indicates the start of a list of directories to update for a set of SYSLEVEL.XXX 
files. The directories may be in one of the following forms: 

- Fully qualified directory name 

- Fully qualified directory name with \* appended to indicate all 
subdirectories below the specific directory 

- < DEFAULT > to include all default directories for the specified syslevels. 

The < default > parameter is would be the preferred parameter as it updates 
all products. 

A \ (backslash) can be used at the end of a line, enabling your :DIRLIST to 
continue onto the next line. :ENDDIRLIST is the matching end tag for 
:DIRLIST. 

Examples of the :DIRLIST syslevel specifiers: 

Fully qualified: <drive> :\<path> <syslevel.xxx> 

This statement will only service the OS/2 base operating system. 
C:\0S2\INSTALL\SYSLEVEL. 0S2 

Drive only: < drive >: 

This will update all syslevel files located on drive C. 

C: 

Drive and Syslevel: < drive > : < sysleveLxxx > : 

This will update all syslevel files with the name SYSLEVEL.OS2 on drive C:. 
C:SYSLEVEL.0S2 

Syslevel only: <syslevel.xxx> 

This will update all SYSLEVEL.OS2 files on all local drives. 

SYSLEVEL. 0S2 

No specifier 

This will update all eligible syslevels corresponding to the products 
contained in the CSD. 

Examples of :DIRLIST statements: 

The first example will update the root and the OS/2 subdirectory tree for 
SYSLEVEL.OS2 on drive C. 

rDIRLIST C:\0S2\INSTALL\SYSLEVEL.0S2 

C:\ 

C:\0S2\* 

: ENDDI RLI ST 

This second example will update all default directories for all syslevel files 
eligible for service with the CSD. This would be the preferred option, as it 
will service all the products on the drive specified. 
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: DIRLIST 
<default> 

: ENDDIRLIST 

• :ENDDIRLIST 

Matching end tag for :DIRLIST 

• :LOGFILE < path\filename > 

Specifies the log file. All logged information will be appended to this file with 
a time stamp as the first entry. The file will be created if it does not already 
exist. This tag will be overridden by the /LI: command-line parameter in the 
FSERVICE statement if it is specified. 

• :FLAGS < flagl > < flag2 > 

This optional tag specifies optional flags. 

The following are the flags options that can be used: 

REPLACEJIEWER 

Replace files that have dates later than the corresponding file on the CSD. If 
this is not specified the user is prompted if any newer files are found. 

SKIP_NEWER 

Do not replace newer files that are found. 

REPLACE_PROTECTED 

Replace files that are read-only, hidden, or system files. If this is not 
specified the user is prompted if any protected files are found. 

SKIP_PROTECTED 

Do not replace protected files. 

NOPROMPT 

Specifies that the user is not to be prompted for any information. 

EXITONERROR 

Specifies that FSERVICE should exit when an error occurs. 

9.1 .1 .3 Sample CSF Service Response Files 

The following response file will allow FSERVICE to perform a default CSD 
installation. 
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•Indicates this is a service 
: SERVICE 

•not backout-enabled as : ARCHIVE is not specified 
: DIRLIST 

•no syslevel specifiers on ; DIRLIST line, use all eligible files 
<DEFAULT> 

•use default directories only 
: ENDDIRLI ST 



Figure 55. Sample Service Response File 

The following response file will allow FSERVICE to perform a service that is 
backout-enabled. 



•indicates this is a service 
: SERVICE 

•backout is enabled 
: ARCHIVE D:\ARCFILES 
•specify a source path 
: $OURCEPATH=Z : \CSD 
•specify a log file 
: LOGFILE W:\CSD.LOG 
•specify a syslevel 
: DIRLIST C: SYSLEVEL. 0S2 
•all directories on drive C 
C:\* 

: ENDDIRLI ST 
•flags specified 

: FLAGS REPLACE NEWER REPLACE PROTECTED 
: FLAGS EXITONERROR 



Figure 56. Sample of a Backout-Enabled Service Response File 

The following response file will allow FSERVICE to perform a commit service. 



•indicates this is a commit 
:CCMMIT C:\SYSLEVEL.0S2 
•specify source path 
: SOURCEPATH=Z :\CSD 
•specify log file 
: LOGFILE W:\CSD.LOG 
: FLAGS EXITONERROR 



Figure 57. Sample of a Commit-Enabled Response File 

If :BACKOUT was used instead of :COMMIT the service would back out and 
return the operating system to its original level. 

9.1 .1 .4 Response File Recognition 

The CSF response file can reside on either the client workstations LT diskette or 
on the server workstation, using the LT diskette CONFIG.SYS, SET OS2_SHELL 
statement to specify response file location. 

Normally the response file will reside on the server. The following is an example 
of the SET OS2_SHELL statement: 
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SET 0S2_SHELL=z : \fservi ce . exe Z:\response.fil 

RESPONSE.FIL is the response file that will be used residing on the server 
workstation. 

9.1.2 Logging Information 

The CSF program will log information pertaining to the service being applied. 
This information includes: 

• Components serviced 

• Date of service 

• Directories serviced 

• Files serviced. 

Unless otherwise specified in the CSF response file :LOGFILE tag, the log file will 
be named SERVICE.LOG and will reside in OS2MNSTALL directory. If the file 
already exists then logging information will be appended. 

9.1.3 Interrupted Service 

If the process is interrupted (after a power failure for example) it can simply be 
restarted by rebooting the install diskette and going through the installation 
process again. 

Files already updated will not be replaced again due to the checking process 
performed by CSF (as explained in 9.2.2, “Installation Method” on page 116). 

9.1.4 CSF for OS/2 Version 1.3 

The CSF for OS/2 V2.0 is also available for use under OS/2 VI. 3. The 
CONFIG.SYS file resides on the first CSD diskette. The CONFIG.SYS in this case 
only has the PROTSHELL statement and does not use the SET OS2_SHELL 
statement as in OS/2 V2.0. The FS1.EXE and FSERVICE.EXE programs both 
appear on the PROTSHELL statement. The FSERVICE parameters for OS/2 V2.0 
are not available for OS/2 VI. 3 CSDs. The default response file namely 
RESPONSE.FIL resides on the second CSD diskette, but can also be copied onto 
the server. 

The following is an example of the PROTSHELL statement with the response file 
residing on drive Z: of the server. 

PROTSHELL=fsl.exe fserv1ce.exe Z:\response.fil 

All of the response file tags can be used except for the :BACKOUT feature, that 
enables a CSD to be backed out and return to its previous level. The 
preparation of the server and client workstation as described below can be 
followed, keeping in mind that the CONFIG.SYS file looks slightly different, and 
that all the :BACKOUT function is not available. 



9.2 Preparation of the Server and Client Workstations 

The process of applying CSD images to client workstations is almost identical to 
the one of installing OS/2 V2.0. The steps are: 
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• Copy the CSD diskettes into a subdirectory structure on the server (as 
described in 9.2.1, “Loading the Corrective Service Diskette (CSD) Images” 
on page 116). 

• Prepare a response file for the workstations using the keywords described in 
9.1. 1.2, “The CSF Response File” on page 111. 

• Create the client LT diskette using the technique in the chapter which 
describes your LAN redirection method. If using TCP/IP, see section 6.3.3, 
“Preparation of the NFS Client LT Diskette” on page 40. For Novell, see 
section 7.3.3, "Preparation of the Novell LT Diskettes” on page 72. For IBM 
LAN Server RIPL, change the RIPLRFI.CMD batch file in the 
\IBMLAN\RPL\OS2.20\OS2\INSTALL directory of the server so that it calls 
FS1.EXE as described below. 

• Modify the client LT diskette so that the CSF programs are called rather than 
RSPINST. 

The following examples assume the the CSD images are accessed as the Z:\ 
directory from the client. The CSF response file is called RESPONSE. FIL and 
has been placed at the root of the CSD images on the server. 

— If your client LT diskette calls RSPINST directly from the PROTSHELL line 
of CONFIG.SYS, change the PROTSHELL to FS1.EXE, and the SET 
OS2_SHELL to FSERVICE.EXE. 

PR0TSHELL=Z s\FSl.EXE 

SET 0S2_SHELL-Zs\FSERVICE.EXE Z:\RESP0NSE.FIL 

— If you client LT diskette calls a command file from the PROTSHELL, 
change the line in the command file which calls RSPINST.EXE to: 

Z:\FS1.EXE Z:\FSERVICE.EXE Z:\RESPONSE.FIL 

9.2.1 Loading the Corrective Service Diskette (CSD) Images 

The CSD diskettes have to be loaded on the server using XCOPY. Load the 
diskettes following these steps: 

1. Create a suitable directory on the server using the MD command: 

MD D:\CSD 

2. Copy all CSD diskettes to the directory using XCOPY: 

XCOPY A: D:\CSD /S 

The following tree is created: 

D:\CSD 

\FIX 

\0S2 



9.2.2 Installation Method 

CSF will not automatically replace every file. The date, time and file name are 
checked to determine if the file on the CSD is different from the one installed. If 
the data matches, then no replacement of that file will occur. This eliminates the 
time involved in replacing all files on the system when only a subset have to be 
replaced. 

At the end of this process, the SYSLEVEL files corresponding to the serviced 
products will be updated to reflect the new levels. 
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Appendix A. Response File Keyword Reference, Samples And 
Details 



The following is a list of all Keywords in the response file that are supported by 
the OS/2 V2.0 installation process. 

AlternateAdapter 

BaseFileSystem 

CDROM 

ConfigSysLine 

Copy 

CountryCode 

CountryKeyboard 

DDIDDP 

DDIDest 

DDISrc 

DefaultPrinter 

DiagnosticAids 

DisplayAdapter 

Documentation 

DOSEnvironment 

DPMI 

EarlyllserExit 

Exi sti n g Wi n dows Path 

ExitOnError 

Extendedlnstall 

Fonts 

FormatPartition 

ID 

Include 

Mig rate Appl ications 

MigrateConfigFiles 

MoreBitmaps 

Mouse 

MousePort 

OptionalFileSystem 

OptionalSystemUtilities 

OS2lniData 

PrimaryCodePage 

PrinterPort 

ProcessEnvironment 

Progresslndication 

RebootRequired 

REXX 

SeedConfigSysLine 

SerialDeviceSupport 

ShareDesktopConfigFiles 

SourcePath 

TargetDrive 

ToolsAndGames 

UserExit 

Version 



© Copyright IBM Corp. 1992 
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WIN-OS/2Desktop 
Windowed WIN-OS/2 

Following the Keyword description there is an example of a response file and 
showing how the different Keywords options can be used, allowing each 
workstation to be configured uniquely by using an included response file. 



A.1 Keyword Description 

The following is a short description of all the Keywords and valid entries that can 
be used in a response file. See sample response files below. 

• AlternateAdapter 

Specifies secondary adapter for two display systems. This should be a lower 
or equal resolution display since the highest resolution display will be 
primary for Presentation Manager. 

0 = None (DEFAULT) 

1 = Other than following (DDINSTAL will handle) 

2 = Monochrome/Printer Adapter 

3 = Color Graphics Adapter 

4 = Enhanced Graphics Adapter 

5 = PS/2 Display Adapter 

6 = 8514/A Adapter 

7 = XGA Adapter 

• BaseFileSystem 

Specifies which file system should be used to format the install partition. For 
example, HPFS or FAT. 

1 = HPFS (DEFAULT) 

2 = FAT 

• CDROM 

Specifies which, if any, CD ROM IFS files should be installed. 

0 = None 

1 = All 

2 = CD-ROM IFS (DEFAULT) 

3 = IBM CD-ROM Device Drivers 

• ConfigSysLine 

Specifies a text line to be appended to CONFIG.SYS. There may be multiple 
occurrences of this keyword. No validity checking is done, therefore 
statements entered into the CONFIG.SYS must be correct. 

KEYVALUE=a valid CONFIG.SYS statement 

• Copy 

Specifies a source file from either the client, or the server to be copied to a 
destination directory on the client or server during the install process. 

Errors are ignored, though they will be logged in the INSTALL.LOG file, in the 
install directory of the client C:\OS2\INSTALL. For example, there could be a 
copy statement, that copies a file from the client to the server. 

Copy statements are executed on completion of the installation of each 
"diskette.” The reason being that the user may not be sure when the file will 
be available to be copied, therefore repeating the copy after each diskette. 
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There may be multiple occurrences of this keyword. No validity checking is 
done. 

Note: The command issued is not the OS/2 COPY command, it is an 
UNPACK command. Therefore the file that is being unpacked must be 
unpacked to its original name. 

KEYVALUE=sourcef il e destination 

source file = valid filename 
destination = valid directory name 

Example: Copy = c:\text.dat z:\ 

CountryCode 

Specifies which country code should be installed. This causes ail country 
information to be installed. Use of this keyword will not update the Country 
panel in System Setup, or the WIN-OS2 panel. 



Country Country 


Codepage 


code 








785 


Arabic-speaking 


864 




099 


Asian English 


437, 


850 


061 


Australia 


437, 


850 


032 


Bel gi um 


437, 


850 


002 


Canada (French-speaking) 


863, 


850 


045 


Denmark 


865, 


850 


358 


Finland 


437, 


850 


033 


France 


437, 


850 


049 


Germany 


437, 


850 


972 


Hebrew-speaking 


862 




039 


Italy 


437, 


850 


081 


Japan 


932 




082 


Korea 


934 




003 


Latin America 


437, 


850 


031 


Netherlands 


437, 


850 


047 


Norway 


865, 


850 


351 


Portugal 


860, 


850 


086 


Simplified Chinese 


936 




034 


Spain 


437, 


850 


046 


Sweden 


437, 


850 


041 


Switzerland 


437, 


850 


088 


Traditional Chinese 


938 




044 


United Kingdom 


437, 


850 


001 


United States 


437, 


850 


CountryKeyboard 






2-5 character keyboard code. 






BE 


= Belgium 






CF 


= Canada, French Speaking 






DK 


= Denmark 






SU 


= Finland 






FR 


= France 






FR120 


= France, Enhanced Keyboard 






GR 


= Germany 






IT 


= Italy 






IT142 


= Italy, Enhanced Keyboard 






LA 


= Latin America 






NL 


= Netherlands 






NO 


= Norway 
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PO = Portugal 

SP = Spain 

SV = Sweden 

SF = Switzerland, French 

SG = Switzerland, German 

UK = United Kingdom 

UK168 = United Kingdom, Enhanced Keyboard 

US = United States 

• DDIDDP 

Use OS/2 Device Driver Installation to install external loadable device 
drivers. A Device Driver Profile (a text file with a .DDP file name extension) 
must be provided by the device driver author to control the installation of the 
device driver. 

KEYVALUE=List of .DDP files to install. 

Examp 1 e : DDIDDP=fi 1 el. DDP, f i 1 e2 . DDP 

• DDIDest 

The OS/2 Device Driver Installation Destination. This determines the target 
directory for the device driver (see also DDIDDP and DDISrc). 

KEYVALUE=Di rectory where to copy the device driver files. 

• DDISrc 

The OS/2 Device Driver Installation Source. This determines the source 
directory for the .DDP files (see also DDIDDP and DDISrc). 

KEYVALUE=Di rectory where the .DDP files are 

• DefaultPrinter 

Specifies which default printer to install. 

KEYVALUE=Key value in the corresponding printer table 

0 = None 

See A.5, “Printer Description Table for Printer KEYWORD” on page 130 for a 
complete selection of printers. 

• DiagnosticAids 

Specifies whether or not to install certain Reliability, Availability and 
Serviceability utilities. 

0 = Don't instal 1 

1 = Install (DEFAULT) 

• DisplayAdapter 

Specifies which adapter should override the primary adapter detected by the 
install process. 

0 = Accept as correct (DEFAULT) 

1 = Other than following (DDINSTAL will handle) 

2 = Monochrome/Printer Adapter 

3 = Color Graphics Adapter 

4 = Enhanced Graphics Adapter 

5 = Video Graphics Adapter 
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6 = 8514/A Adapter 

7 = X6A Adapter 

Documentation 

Specifies which documentation should be installed. 

0 = None 

1 = All (DEFAULT) 

2 = OS/2 Command Reference 

3 = OS/2 Tutorial 

4 = Rexx Documentation 

DOSEnvironment 

Specifies whether or not to install DOS. 

0=Don't install 

1=D0S + WIN-OS/2 Environment (DEFAULT) 

2=D0S Environment Only 

DPMI 

Specifies which DOS Protect Mode Interface options to install. 

0 = None 

1 = All (DEFAULT) 

2 = Virtual DOS Protect Mode Interface 

3 = Virtual Enhanced Memory Management 

4 = Virtual Extended Memory Support 

EarlyUserExit 

Specifies a command that can be run before the target drive is is to be 
formatted or copied over. The program is called with the DosExec API. Install 
waits for the program to return. The only difference between this keyword 
and the UserExit keyword is that this one is executed at the very beginning 
of the installation process just after the response file has been interpreted 
while the latter is executed at the very end just before the RSPINST program 
quits execution. 

Note 

Please ignore the description in SAMPLE. RSP on the original OS/2 V2.0 
installation diskettes. 



KEYVALUE=user exit program name (DEFAULT=none) 

For an example on the use of EarlyUserExit refer to A.6.3, “The User Exit 
Keywords of The Response File” on page 136. 

ExistingWindowsPath 

Specifies the path to an existing WINDOWS system. This option is valid only 
when option 1 is selected for the WIN-OS/2Desktop keyvalue. 

KEYVALUE=A string that specifies the path to the existing 
WINDOWS system 

Exampl e : Exi sti ngWi ndowsPath=C: \WI NDOWS 

ExitOnError 

Specifies if the install program should exit with an error code if an error 
occurs. This also determines whether the installation process will exit with a 
return code when it completes rather than the Ctrl-Alt-Del Panel. 
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0 = Do not exit when error occurs; display panel 

(DEFAULT) 

1 = Exit quietly with a return code 

• Extendedlnstall 

Specifies a program to be run asynchronously while the installation process 
continues, this Keyword has been reserved for future use. 

KEYVALUE=ful 1 pathname of program 
(DEFAULT=none) 

• Fonts 



Specifies which fonts should be installed. 

0 = None 

1 = All (DEFAULT) 


2 = Courier 


(Bi tmap) 


3 = Helvetica 


(Bi tmap) 


4 = System Mono-spaced 


(Bi tmap) 


5 = Times Roman 


(Bi tmap) 


6 = Courier 


(Outline) 


7 = Helvetica 


(Outline) 


8 = Times New Roman 


(Outline) 



• FormatPartition 



Specifies whether or not to format the install partition, using HPFS or FAT file 
system chosen in the BaseFileSystem Keyword. 

0 = Do not format (DEFAULT) 

1 = Format 

• ID 

Specifies some identification string that may be may be used by install or 
UserExit to identify the response file(s) used for this Installation. This 
Keyword is user defined. 

KEYVALUE=ASCII string 

• Include 

Specifies another response file which will include additional Keywords or 
override the current response files Keywords. Different include files could 
therefore be used for those specific workstation whose requirements are not 
met by a standard response file. If duplicate Keywords appear, the last 
occurrence will be used. There can be multiple occurrences of this Keyword. 

KEYVALUE=valid filename 

For an example of the use of Include within a response file see A.6.1, “Single 
Include File Sample" on page 133. 

• MigrateApplications 

Specifies whether or not to migrate existing DOS, WINDOWS and OS/2 
applications. Only those applications listed in the database specified will be 
migrated. 

KEYVALUE=Dri ves to search, database to use for search 

Example: Mi grateAppli cat ions=C:D:, C:\0S2\INSTALL\DAT ABASE. DAT 

• MigrateConfigFiles 
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Specifies whether or not to migrate configuration files from a previous 
release of the operating system. Thus allowing your existing CONFIG.SYS to 
be migrated. The AUTOEXEC.BAT for DOS will also be migrated. 

0 = Don't migrate 

1 = Migrate files (DEFAULT) 

MoreBitmaps 

Specifies whether or not to install more bitmaps for the Wallpaper utility. 

0 = Don't install More Bitmaps 

1 = Install More Bitmaps (DEFAULT) 

Mouse 

Specifies which mouse device driver, if any, to install. 

0 = No pointing device support 

1 = PS/2 Style Pointing Device (DEFAULT) 

2 = Bus Version 

3 = Serial Version 

4 = In Port Version 

5 = Logitech (tm) Mouse 

6 = IBM PS/2 Touch Display 

7 = Other Pointing Device for Mouse Port 

MousePort 

Specifies to which port a serial-type mouse should be attached. 

0 = No port necessary (DEFAULT) 

1 = C0M1 

2 = COM2 

3 = COM3 

4 = COM4 

OptionalFileSystem 

Specifies whether or not to install optional file system(s). This option is 
provided so that if you initially decided to install OS/2 using the FAT file 
system, OS/2 will not copy any of the HPFS files to your disk. The user 
might require the use of these HPFS files, and can therefore have the ability 
to install both file systems. For example: the user initially only has one drive 
C: using FAT. At a later stage the user decides to add a extra partition D: 
using HPFS. Using this option, all the necessary DLL files are copied to disk. 

0 = Do Not Install Optional File System(s) 

1 = Install Optional File System (DEFAULT) 

OptionalSystemUtilities 

Specifies whether or not to install the available system utilities. 

0 = Install none 

1 = Install all (DEFAULT) 

2 = Backup Hard Disk 

3 = Change File Attributes 

4 = Display Directory Tree 

5 = Manage Partitions 

6 = Label Diskettes 

7 = Link Object Modules 

8 = Picture Utilities 

9 = PMREXX 

10 = Recover Files 

11 = Restore Backed-up Files 
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12 = Sort Filter 

13 = Installation Aid 

• OS2lniData 

Specifies a profile string to be written to the user configuration file OS2.INI. 
There may be multiple occurrences of this keyword. This statement utilizes 
the PrfWriteProfileString API, defined in PM Programming Reference in the 
chapter “Profile Functions.” Valid keywords are found in the Appendix 
"Initialization File Information". It is possible to add private application 
names with private key names and key values, which can be retrieved by a 
private application using the PrfQueryProfileString API. Application names 
starting with "PM_" are reserved for Presentation Manager. 

KEYVALUE=/AppName/KeyName/KeyValue/ 

NOTE: Since each of these names can contain 
imbedded blanks and whitespace, the "slash" 
character must be used as a delimiter. There 
must be three tokens delineated on all sides or 
this keyword will be ignored. 

Exampl e : 0S2I ni Data=/PM_SP00LER/QUEUE/PSCRIPT2 



This would define the default queue name. 

• PrimaryCodePage 

Specifies whether "national" or "multilingual" code page is primary (first 
active code page before switching). 

1 = National (DEFAULT) 

2 = Multilingual 

• PrinterPort 

Specifies to which printer port the default printer should be attached. 

1 = LPT1 (DEFAULT) 

2 = LPT2 

3 = LPT 3 

4 = C0M1 

5 = COM2 

6 = COM3 

7 = COM4 

• ProcessEnvironment 

Specifies whether or not to add keyword/keyvalues to the environment. This 
makes it easy for primitive programs, batch files, or REXX programs (run as 
a UserExit, for example) to access response file data. Since we're already 
processing the file, these programs will only have to read an environment 
variable. 

0 = Do not add keyword/keyvalues to environment 

1 = Add keyword/keyvalues to environment (DEFAULT) 

• Progresslndication 

Specifies whether or not to display a progress indicator during the 
installation. 

0 = No progress indication 

1 = Progress indication (DEFAULT) 
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RebootRequired 

Specifies if the machine should be automatically warm booted when 
installation is complete. This is ignored if the Extendedlnstall response is 
specified. 

0 = Ask user to reboot (DEFAULT) 

1 = Auto-reboot 

REXX 

Specifies whether or not to install REXX. 

0 = Don't Install REXX 

1 = Install REXX (DEFAULT) 

SeedConfigSysLine 

Specifies a text line to be appended to the CONFIG.SYS written to the seed 
system from which PM Install boots. This will allow device drivers (that may 
be required) to become part of that seed system. There may be multiple 
occurrences of this keyword. No validity checking is done. This Keyword is 
reserved for future use. 

KEYVALUE=a valid CONFIG.SYS statement 

SerialDeviceSupport 

Specifies whether or not to install any serial device driver. 

0 = Don't install 

1 = Install (DEFAULT) 

ShareDesktopConfigFiles 

Specifies that the desktop configuration files should be shared between an 
existing Windows system and the WIN-OS/2 system being installed. If this 
option is selected, the Windows desktop will be updated when changes are 
made to the WIN-OS/2 desktop. This option is valid only when option 1 is 
selected for the WIN-OS/2Desktop keyvalue. 

0=Do not share the WINDOWS desktop configuration files 
l=Share the WINDOWS desktop configuration files 

SourcePath 

Specifies the path that should be used as a source drive and directory from 
which to install the disk images. This Keyword is optional, as you could set 
the SourcePath parameter in the CONFIG.SYS file on the LT diskette. If 
however this Keyword is used in the response file for the client it will 
override the SourcePath statement in the CONFIG.SYS file on the LT diskette. 

KEYVALUE=dri ve and optional path (D:\OS2SE20\...) 

DEFAULT=A:\ 

TargetDrive 

Specifies the target drive to which OS/2 should be installed. This drive is 
assumed to be a valid partition. If a partition other than C: is specified, it is 
assumed that Boot Manager is already installed to enable booting an 
operating system from different partitions. 

KEYVALUE=C: 

ToolsAndGames 

Specifies which tools or games can be installed. 
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0 = Install none 

1 = Install all (DEFAULT) 

2 = Enhanced Editor 

3 = Search and Scan Tool 

4 = Terminal Emulator 

5 = Chart Maker 

6 = Personal Productivity 

7 = Solitaire - Klondike 

8 = Reversi 

9 = Scramble 

10 = Cat and Mouse 

11 = Pulse 

12 = Jigsaw 

13 = Chess 

Example: ToolsAndGames=2,8,13 

• UserExit 

Specifies the name of a program that can be run at the end of the install 
procedure. This Keyword may occur more than once. Each will be executed 
in the order that they appear at the end of OS/2 Install. 

KEYVALUE=user exit program name (DEFAULT=none) 

For an example of the use of UserExit refer to A.6.3, “The User Exit 
Keywords of The Response File” on page 136. 

• Version 

Specifies specific version of the operating system for which this file is 
intended. This Keyword is user defined. 

KEYVALUE=User defined version string 

• WIN-OS/2Desktop 

Specifies what the WIN-OS/2 desktop should look like. This option is valid 
only when option 1 (WIN-OS/2 Support) is selected for the DOSEnvironment 
keyvalue. Option 1 should be selected only if Windows is currently installed 
(see ExistingWindowsPath and ShareDesktopConfigFiles also). Option 2 
should be selected only if WIN-OS/2 has previously been installed. 

0=lnstall standard WIN-OS/2 desktop (DEFAULT) 

l=Copy existing WINDOWS desktop and use as the WIN-OS/2 desktop 

2=Preserve WIN-OS/2 desktop currently installed 

• WindowedWIN-OS/2 

Specifies whether Windows applications should run in windowed sessions on 
the Presentation Manager desktop or in Full Screen sessions. This option is 
valid only when option 1 (WIN-OS/2 Support) is selected for the 
DOSEnvironment keyvalue. Systems with (VGA) resolution will always 
receive WIN-OS/2 sessions that run in a window as the default. 

0=Windowed WIN-OS/2 sessions (Requires medium resolution (VGA) video) 
l=Full Screen WIN-OS/2 sessions (Run with highest resolution video 
possible) 



126 OS/2 V2.0 Remote Installation 




A.2 How to Edit the Response File 

• The response file is a flat ASCII file so it can easily be edited and 
manipulated. 

• Comments may appear anywhere in the file. The comment character is the 
asterisk Any line beginning with this character, will be ignored. 

• Blank lines are ignored. 

• All OS/2 System Installation process response statements must have the 
following format: 

KEYWORD = parm,parm,parm 

If the Keyword has the option to choose more than one parameter, the user 
can do so as long as they are separated by a comma, and do NOT include 
the default parameter. 

• Statements do not need to start in the first column. 

• The Keywords may appear in any order. If a duplicate Keyword exists the 
last one found will be used. 

• Keywords and "parm" values are not case sensitive. 

• Blanks and white spaces on any lines are ignored in the Keyword portion of 
the line. This is the portion preceding the delimiter "=". 

• Blanks and white spaces are preserved in the "parm" portion of a response 
line. This is the portion following the delimiter "=". 

• "parm" is an ASCII-numeric value (whereever possible) or a file specification 
to avoid typing problems and translation problems. 

• The entire response file is processed before the rest of the installation 
occurs. 



A.3 Sample Response Files 

Although the response file Keywords don't have to be in any specific sequence 
in order to work, the following response file has been divided into 3 phases to 
make it easier for the user to understand how the response file installation takes 
place. The second sample is a response file which is used to produce the 
Installation Log shown in Appendix B, “Installation Log” on page 139. 

Phase 1 



This would be the preparation stage for the response file to work. In the 
example below we have copied all the files in the data directory of the client 
onto the server's shared drive Z:. Because we have used the EarlyUserExit 
Keyword, this copy will take place before the client disk is formatted. 

Phase 2 • 

At this stage the user would be prompted to answer certain questions about the 
installation process. For example, “Do you want to format your drive?” or “What 
type of mouse are you using?” 

Phase 3 
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This is the stage after the installation has completed, and the user may want to 
add some extra lines to the CONFIG.SYS file, or do a UserExit that will run a 
program that copies the install.log to the server machine, and then reboot the 
system. 
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* PHASE 1 (Commands executed before Installation takes place) 
Copy=c:\data\ zs\ 

EarlyUserExit=copy c:\data\*.* z:\ 

Exi st i ngWi ndows Pat h-C : \wi ndows 
Exit0nError=8 

Extendedlnstal 1 ^backup .exe 
Include=teller.rsp 

Hi grateAppl i cat i ons=C : D; , C : \OS2\INSTALL\DATABASE . DAT 

H1grateConfigF11es s l 

ShareDesktopConf igFil es=l 

SourcePath-d: \os2se28 . rsp 

Version°Version2.8 

WIN-0S/2Desktop=l 

Wi ndowedWI N-0S/2=1 

* PHASE 2 (Answers to installation process questions) 

AlternateAdapter=6 

BaseFileSystem-2 

CDR0M=2 

CountryCode=001 

CountryKeyboard=US 

Def aul t Pr i nter=58 

DiagnosticAids=l 

DisplayAdapter=0 

Documentation^!. 

DOSEnvironment=l 

DPHI=1 

Fonts=l 

FormatPartiti on=l 

ID-ASCII string 

HoreBitmaps=l 

House=l 

HousePort=0 

Opt i onal Fi 1 eSystem=l 

Opt 1 onal Syst emUt i 1 1 t 1 es=l 

0S2IniData= 

Pr i maryCodePage=l 
PrinterPort=l 
Process Environments 
Progress Ind i cat i on=l 
REXX=1 

Serial Devi ceSupportS 
Target Drive=C: 

Tool sAndGamesS 

* PHASE 3 (Post installation procedures before reboot takes place) 

DDIDDP-FIOAUX.DDP 

DDIDest°C:\os2 

DDISrc=z:\ 

Conf i gSysLi ne=Devi ce=c s \osl\ega . sys 

RebootRequiredS 

User Exi t=userl og . exe 



Figure 58. Sample Response File Divided into Three Phases 
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A.4 Sample Response File 



A1 ternateAdapter=9 

BaseFileSystem=2 

CDROH-2 

CountryCode=001 

CountryKeyboard=US 

DefaultPrinter=0 

Diagno$ticAids=l 

Di spl ayAdapter-0 

Documentation-1 

DOSEnvironment=l 

DPHI=1 

ExitOnError=0 

Fonts=l 

Format Part i t i on=0 

Incl ude=x : \i ndi v . rsp 

Hi grateConf i gFi 1 es=0 

HoreBitmaps=l 

House-1 

HousePort s 0 

Opt i onal Fi 1 eSy stem=l 

Opt i onal Syst emllt i 1 i t i es=4 , 5 , 9 , 13 

0S2Ini Data=/AppHame/KeyName/KeyVal ue/ 

Pr i tnaryCodePage=l 

PrinterPort=l 

ProcessEnvironment=l 

Progresslndi cat i on=l 

Reboot Required=0 

REXX=1 

Serial Devi ceSupport-1 
Target Dr ive=D: 

ToolsAndGames-1 

ID-0S2SE20 Sample Response File 
UserExit-N:\NWINST.CHD 



Figure 59. Response File Used for Sample Installation Log 



A.5 Printer Description Table for Printer KEYWORD 

A list of printers (PRDESC.LST) resides on the first printer device driver diskette. 
The list below has a keyvalue column added for easier indexing. On the contrary 
the list on the diskette shows no line numbers, therefore the number must be 
calculated by counting the number of lines up to the appropriate printer. 

Note: The list below does not necessarily reflect the current list on the first 
printer device driver diskette. 



| Keyvalue Description 


Device type 


Oriver name 


1 


AST TurboLaser 


AST TurboLaser 


(PSCRIPT.DRV) 


2 


Agfa Matrix ChromaScript v51_8 


Agfa Matrix ChromaScript v51_8 


(PSCRIPT.DRV) 


3 


Agfa-Compugraphic 94C0PS v49_3 


Agfa-Compugraphic 94G0PS v49_3 


(PSCRIPT.DRV) 


4 


Agfa/Compugraphic 4C0PS 


Agfa/Compugraphic 4G8PS 


(PSCRIPT.DRV) 


5 


Apple LaserWriter II NT 


Apple LaserWriter II NT 


(PSCRIPT.DRV) 


6 


Apple LaserWriter II NTX 


Apple LaserWriter II NTX 


(PSCRIPT.DRV) 


7 


Apple LaserWriter Plus v42_2 


Apple LaserWriter Plus v42_2 


(PSCRIPT.DRV) 


8 


Apple LaserWriter Plus 


Apple LaserWriter Plus 


(PSCRIPT.DRV) 
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Keyvatue 


Description 


Device type 


Driver name 


9 


Apple LaserWriter 


Apple LaserWriter 


(PSCRIPT.DRV) 


10 


Cclormate PS v51 9 


Colormate PS v51 9 


(PSCRIPT.DRV) 


11 


Dataproducts LZR 1260 v47 0 


Dataproducts LZR 1260 v47_0 


(PSCRIPT.DRV) 


12 


Dataproducts LZR-2665 


Dataproducts LZR-2665 


(PSCRIPT.DRV) 


13 


Digital LN03R ScriptPrintor 


Digital LN03R ScriptPrinter 


(PSCRIPT.DRV) 


14 


Digital LPS Print Server 40 


Digital LPS PrintServer40 


(PSCRIPT.DRV) 


15 


Epson 24 pins - 136 columns 


24-pin 136 Col 


(EPSON.DRV) 


16 


Epson 24 pins * 80 columns 


24-pin 80 Col 


(EPSON. DRV) 


17 


Epson 9 pins - 136 columns 


9-pin 136 Col 


(EPSON.DRV) 


18 


Epson 9 pins - 80 columns 


9-pin 80 Col 


(EPSON.DRV) 


19 


Epson DFX-5000 9 pins * 136 columns 


DFX-5000 


(EPSON.DRV) 


20 


Epson DFX-8000 9 pin - 136 column 


DFX-8000 


(EPSON.DRV) 


21 


Epson EPL*6000 Laser 


EPL-6000 


(EPSON.DRV) 


22 


Epson E PL-7000 


Epson EPL-7000 


(LASERJET.DRV) 


23 


Epson EPL-7500 v52_3 


Epson EPL-7500 v52 3 


(PSCRIPT.DRV) 


24 


Epson EX-1000 Color 9 pins - 136 columns 


EX-1000 


(EPSON.DRV) 


25 


Epson EX-800 Color 9 pins - 80 columns 


EX-800 


(EPSON.DRV) 


26 


Epson FX-1G50 9 pins - 136 columns 


FX-1050 


(EPSON.DRV) 


27 


Epson FX-286e 9 pins • 136 columns 


FX-286e 


(EPSON.DRV) 


28 


Epson FX-850 9 pins - 80 columns 


FX-850 


(EPSON.DRV) 


29 


Epson JX-60 Color 9 pins - 80 columns 


JX-80 


(EPSON.DRV) 


30 


Epson LQ-1010 24 pin - 132 column 


LQ-1010 


(EPSON.DRV) 


31 


Epson LQ-1050 (N9) 24 pins • 136 columns 


LQ-1050 (N9) 


(EPSON.DRV) 


32 


Epson LQ-1050 24 pins -136 columns 


LQ-1050 


(EPSON.DRV) 


33 


Epson LQ-1170 24 pins * 136 columns 


LQ-1170 


(EPSON.DRV) 


34 


Epson LQ-2500 Color 24 pins * 138 columns 


LQ-2500 


(EPSON.DRV) 


35 


Epson LQ-2550 Color 24 pins * 136 columns 


LQ-2550 


(EPSON.DRV) 


36 


Epson LQ-500 24 pins - 80 columns 


LQ-500 


(EPSON.DRV) 


37 


Epson LQ-510 24 pins • 80 columns 


LQ-510 


(EPSON.DRV) 


38 


Epson LQ-570 24 pins - 80 columns 


LQ-570 


(EPSON.DRV) 


39 


Epson LQ-850 (N9) 24 pins - 80 columns 


LQ-850 (N9) 


(EPSON.DRV) 


40 


Epson LQ-850 24 pins - 80 columns 


LQ-850 


(EPSON.DRV) 


41 


Epson LQ-860 Color 24 pins - 80 columns 


LQ-860 


(EPSON.DRV) 


42 


Epson LQ-870 24 pins - 80 columns 


LQ-870 


(EPSON.DRV) 


43 


Epson LQ-950 (N9) 24 pins - 110 columns 


LQ-850 (N9) 


(EPSON.DRV) 


44 


Epson LX-800 9 pins - 80 columns 


LX-800 


(EPSON.DRV) 


45 


Epson LX-810 9 pins - 80 columns 


LX-810 


(EPSON.DRV) 


46 


Generic PostScript Printer 


Generic PostScript Printer 


(PSCRIPT.DRV) 


47 


HP 7470A Plotter 


HP7470A 


(PLOTTERS.DRV) 


48 


HP 7475A Plotter 


HP7475A 


(PLOTTERS.ORV) 


49 


HP 7550A Plotter 


HP7550A 


(PLOTTERS.DRV) 


50 


HP 7580A Plotter 


HP7580A 


(PLOTTERS.DRV) 


51 


HP 7580B Plotter 


HP7580B 


(PLOTTERS.DRV) 


52 


HP 7585A Plotter 


HP7585A 


(PLOTTERS.DRV) 


53 


HP 7585B Plotter 


HP7585B 


(PLOTTERS.DRV) 


54 


HP 7586 B Plotter 


HP7586B 


(PLOTTERS.DRV) 


55 


HP ColorPro 


HP7440A 


(PLOTTERS.DRV) 


56 


HP DeskJet 500 in Epson EPL-6000 mode 


HP DeskJet 500 


(EPSON.DRV) 


57 


HP DraftMaster 1 


HP7585A 


(PLOTTERS.DRV) 


58 


HP DraftMaster II 


HP7598A 


(PLOTTERS.DRV) 


59 


HP DraftPro 


HP7570A 


(PLOTTERS.DRV) 


60 


HP LaserJet 2000 


HP LaserJet 2000 


(LASERJET.DRV) 


61 


HP LaserJet 500 Plus 


HP LaserJet 500 Plus 


(LASERJET.DRV) 


62 


HP LaserJet Classic 


HP LaserJet Classic 


(LASERJET.DRV) 


63 


HP LaserJet IID vS2 2 


HP LaserJet IID v52_2 


(PSCRIPT.DRV) 


64 


HP LaserJet IID 


HP LaserJet IID 


(LASERJET.DRV) 


65 


HP LaserJet III v52 2 


HP LaserJet III v52_2 


(PSCRIPT.DRV) 


66 


HP LaserJet III 


HP LaserJet III 


(LASERJET.DRV) 


67 


HP LaserJet HID v52_2 


HP LaserJet HID v52 2 


(PSCRIPT.DRV) 


66 


HP LaserJet HID 


HP LaserJet HID 


(LASERJET.DRV) 


69 


HP LaserJet HIP PS v52_2 


HP LaserJet (IIP PS v52 2 


(PSCRIPT.DRV) 


70 


HP LaserJet HIP 


HP LaserJet HIP 


(LASERJET.DRV) 


71 


HP LaserJet IllSi PS v52_3 


HP LaserJet IllSi PS v52 3 


(PSCRIPT.DRV) 


72 


HP LaserJet IllSi 


HP LaserJet IllSi 


(LASERJET.DRV) 


73 


HP LaserJet HP Plus 


HP LaserJet HP Plus 


(LASERJET.DRV) 


74 


HP LaserJet HP v52 2 


HP LaserJet IIP v52_2 


(PSCRIPT.DRV) 


75 


HP LaserJet HP 


HP LaserJet HP 


(LASERJET.DRV) 


76 


HP LaserJet Plus 


HP LaserJet Plus 


(LASERJET.DRV) 


77 


HP LaserJet Series II 


HP LaserJet Series II 


(LASERJET.DRV) 


78 


IBM 2380 PPS II 


IBM 2380 PPS II 


(IBM42XX.DRV) 


79 


IBM 2381 PPS II 


IBM 2381 PPS II 


(IBM42XX.DRV) 


80 


IBM 2380 PPS II 


IBM 2380 PPS II 


(IBM42XX.DRV) 


81 


IBM 2391 PPS II 


IBM 2391 PPS II 


(IBM42XX.DRV) 


82 


IBM 3816 - 01 D 


IBM 3816 * 01 D 


(IBM52XX.DRV) 


83 


IBM 3816 - 01 S 


IBM 3816 • 01S 


(IBM52XX.DRV) 


84 


IBM 4019 LaserPrinter E 


IBM 4019 Laserprinter 6 


(IBM4019.DRV) 


85 


IBM 4019 LaserPrinter 


IBM 4019 Laserprinter 


(IBM4019.DRV) 


86 


IBM 4019 Laserprinter E 


IBM 4019 Laserprinter £ 


(LASERJET.DRV) 


87 


IBM 4019 Laserprinter 


IBM 4019 Laserprinter 


(LASERJET.DRV) 


88 


IBM 4019 v52 1:(17 Fonts) 


IBM 4019 v52 1 (17 Fonts) 


(PSCRIPT.DRV) 


89 


IBM 4019 v52 1 (39 Fonts) 


IBM 4019 v52 1 (39 Fonts) 


(PSCRIPT.DRV) 


80 


IBM 4029 (17 Fonts 300 Dpi) 


IBM 4029 (17 Fonts 300 Dpi) 


(PSCRIPT.DRV) 


91 


IBM 4029 (17 Fonts 600 Dpi) 


IBM 4029 (17 Fonts 600 Dpi) 


(PSCRIPT.DRV) 


92 


IBM 4029 (39 Fonts 300 Dpi) 


IBM 4029 (39 Fonts 300 Dpi) 


(PSCRIPT.DRV) 


93 


IBM 4029 (39 Fonts 600 Dpi) 


IBM 4029 (39 Fonts 600 Dpi) 


(PSCRIPT.DRV) 


94 


IBM 4029 LaserPrinter 10 


IBM 4029 Laserprinter 10 


(IBM4019.DRV) 


85 


IBM 4029 LaserPrinter 1QL 


IBM 4029 LaserPrinter 10L 


(IBM4019.DRV) 


86 


IBM 4029 Laserprinter 5E 


IBM 4029 Laserprinter 5E 


(IBM4019.DRV) 


97 


IBM 4029 LaserPrinter 6 


IBM 4029 LaserPrinter 6 


(IBM4019.DRV) 


88 


IBM 4029 Laserprinter 10 


IBM 4029 Laserprinter 10 


(LASERJET.DRV) 


89 


IBM 4029 Laserprinter 10L 


IBM 4029 Laserprinter 10L 


(LASERJET.DRV) 
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Keyvalue Deecrlption 


Device type 


Driver name 


100 


IBM 4029 Laserprinter 5E 


IBM 4029 Leserprinter 5E 


(LASERJET. DRV] 


101 


IBM 4029 Laaerprirrter 6 


IBM 4029 Leserprinter 6 


(LASERJET. DRV) 


102 


IBM 4201 Proprinter II 


IBM 4201 Proprinter II 


(IBM42XX.DRV) 


103 


IBM 4201 Proprinter III 


IBM 4201 Proprinter III 


(IBM42XX.DRV) 


104 


IBM 4201 Proprinter 


IBM 4201 Proprinter 


(IBM42XX.DRV) 


108 


IBM 4202 Proprinter II XL 


IBM 4202 Proprinter II XL 


(IBM42XX.DRV) 


108 


IBM 4202 Proprinter III XL 


IBM 4202 Proprinter III XL 


(IBM42XX.DRV) 


107 


IBM 4202 Proprinter XL 


IBM 4202 Proprinter XL 


(IBM42XX.DRV) 


108 


IBM 4207 Proprinter X24 


IBM 4207 Proprinter X24 


(IBM42XX.DRV) 


109 


IBM 4207 Proprintar X24E 


IBM 4207 Proprinter X24E 


(IBM42XX.DRV) 


110 


IBM 4208 Proprinter XL24 


IBM 4208 Proprinter XL24 


(IBM42XX.DRV) 


111 


IBM 4208 Proprinter XL24E 


IBM 4208 Proprinter XL24E 


(IBM42XX.DRV) 


112 


IBM 4216*031 v51 4 SheotFeed 


IBM 4216-031 v51 4 SheetFeed 


(PSCRIPT.DRV) 


113 


IBM 4224 - 01 & 02 & E3 


IBM 4224 • 01 & 02 & E3 


(IBM42XX.DRV) 


114 


IBM 4224 - C2 


IBM 4224 • C2 


(IBM42XX.DRV) 


115 


IBM 4226 Modal 302 


IBM 4226 Model 302 


(IBM42XX.DRV) 


116 


IBM 5201 Quietwriter II 




(IBM52012.DRV) 


117 


IBM 5202 QuietWriter III 


IBM 5202 QuietWriter III 


(IBM52XX.DRV) 


118 


IBM 5204 QuickWriter 


IBM 5204 QuickWriter 


(IBMS2XX.DRV) 


119 


IBM 6180 Plotter 


IBM6180 


(PLOTTERS.DRV) 


120 


IBM 6182 Plotter 


IBM8182 


(PLOTTERS.DRV) 


121 


IBM 8184 Plotter 


IBM6184 


(PLOTTERS.DRV) 


122 


IBM 6186*1 Plotter 


IBM6186-1 


(PLOTTERS.DRV) 


123 


IBM 6186*2 Plotter 


IBM6186-2 


(PLOTTERS.DRV) 


124 


IBM 7371 Plotter 


(BM7371 


(PLOTTERS.DRV) 


125 


IBM 7372 Plotter 


IBM7372 


(PLOTTERS.DRV) 


126 


IBM 7374 Plotter 


IBM7374 


(PLOTTERS.DRV) 


127 


IBM 7375-1 Plotter 


IBM7375-1 


(PLOTTERS.DRV) 


128 


IBM 7375-2 Plotter 


IBM7375-2 


(PLOTTERS.DRV) 


129 


IBM NULL Printer Oliver 




(IBMNULL.DRV) 


130 


IBM Personal Page Printer 11-30 


IBM Personal Page Printer 11-30 


(PSCRIPT.DRV) 


131 


IBM Personal Page Printer 11*31 


IBM Personal Page Printer 11-31 


(PSCRIPT.DRV) 


132 


IBM Personal Pageprimer 


IBM Personal Pageprirttar 


(PSCRIPT.DRV) 


133 


Kyocera F-10C0A/F-1C0O 


Kyocera F-1000A/F-1000 


(LASERJET. DRV) 


134 


Kyocera F-1800A/F-1800 


Kyocera F-1800A/F-1800 


(LASERJET. DRV) 


135 


Kyocera F-2000A/F-2200S 


Kyocera F-2000A/F-2200S 


(LASERJET. DRV) 


136 


Kyocera F-300QA/F-3300 


Kyocera F-30C0A/F-3300 


(LASERJET. DRV) 


137 


Kyocera F-5000A/F-5000 


Kyocera F-5000A/F-5000 


(LASERJET. DRV) 


138 


Kyocera F-800A/F-800 


Kyocera F-600A/F-800 


(IASERJET.DRV) 


139 


Kyocera F-820 


Kyocera F-820 


(LASERJET.DRV) 


140 


Kyocera P-2000 


Kyocera P-2000 


(PSCRIPT.DRV) 


141 


Kyocera Q-8010 


Kyocera Q-8010 


(PSCRIPT.DRV) 


142 


Linotrcnic 100 v38 0 


Linotronic 100 v38 0 


(PSCRIPT.DRV) 


143 


Linotronic 100 v42 5 


Linotronic 100 v42 5 


(PSCRIPT.DRV) 


144 


Linotronic 200 v47 1 


Linotronic 200 v47_1 


(PSCRIPT.DRV) 


145 


Linotronic 200 v49 3 


Linotronic 200 v49_3 


(PSCRIPT.DRV) 


146 


Linotrontc 300 v47_0 


Linotronic 300 v47_0 


(PSCRIPT.DRV) 


147 


Linotronic 300 v47_1 


Linotronic 300 v47_1 


(PSCRIPT.DRV) 


148 


Linotronic 300 v49_3 


Linotronic 300 v49_3 


(PSCRIPT.DRV) 


149 


Linotronic 500 v49_3 


Linotronic 500 v49_3 


(PSCRIPT.DRV) 


150 


Micrografx PaintJet Presentation Driver 


PaintJet 


(SMGXPJET.DRV) 


151 


Micrografx PaintJet Presentation Driver 


PaintJet XL 


(SMGXPJET.DRV) 


152 


NEC LC-890 


NEC LC-890 


(PSCRIPT.DRV) 


153 


Olivetti LP 5000 


Olivetti LP 5000 


(PSCRIPT.DRV) 


154 


Panasonic KX-P1123 in Epson LQ-850 mode 


Panasonic KX-P1123 


(EPSON. DRV) 


155 


Panasonic KX-P1124 in Epson LQ-25C0 mode 


Panasonic KX-P1124 


(EPSON. DRV) 


156 


Panasonic KX*P1124i in Epson LQ-850 mode 


Panasonic KX-P1124i 


(EPSON. DRV) 


157 


Panasonic KX-P1180 in Epson FX-86e mode 


Panasonic KX-P1180 


(EPSON. DRV) 


158 


Panasonic KX-P1191 in Epson FX-86e mode 


Panasonic KX-P1191 


(EPSON. DRV) 


159 


Panasonic KX-P1624 in Epson LQ-2500 mode 


Panasonic KX-P1624 


(EPSON. DRV) 


160 


Panasonic KX-P1654 in Epson LQ-1050 mode 


Panasonic KX-P1654 


(EPSON. DRV) 


161 


Panasonic KX-P1695 in Epson FX-1050 mode 


Panasonic KX-P1695 


(EPSON. DRV) 


162 


Panasonic KX-P2624 in Epson LQ-1050 mode 


Panasonic KX-P2624 


(EPSON. DRV) 


163 


Panasonic KX-P4420 


Panasonic KX-P4420 


(LASERJET.DRV) 


164 


Panasonic KX-P4450 


Panasonic KX-P4450 


(LASERJET.DRV) 


165 


Panasonic KX-P4450i 


Panasonic KX-P4450i 


(LASERJET.DRV) 


166 


Panasonic KX-P4455 v51_4 


Panasonic KX-P4455 v51_4 


(PSCRIPT.DRV) 


167 


Phaser Card v1_1 


Phaser Card vl 1 


(PSCRIPT.DRV) 


168 


QMS ColorScript 100 Mod 10 


QMS ColorScript 100 Mod 10 


(PSCRIPT.DRV) 


169 


QMS ColorScript 100 Mod 30 


QMS ColorScript 100 Mod 30 


(PSCRIPT.DRV) 


170 


QMS ColorScript 100 Mod 30si 


QMS ColorScript 100 Mod 30si 


(PSCRIPT.DRV) 


171 


QMS ColorScript 100 


QMS ColorScript 100 


(PSCRIPT.DRV) 


172 


QMS IS X320T 


QMS IS X320T 


(PSCRIPT.DRV) 


173 


QMS-PS 1500 


QMS-PS 1500 


(PSCRIPT.DRV) 


174 


QMS-PS 2000 


QMS-PS 2000 


(PSCRIPT.DRV) 


175 


QMS-PS 2200 


QMS-PS 2200 


(PSCRIPT.DRV) 


176 


QMS-PS 2210 


QMS-PS 2210 


(PSCRIPT.DRV) 


177 


QMS-PS 2220 


QMS-PS 2220 


(PSCRIPT.DRV) 


178 


QMS-PS 410 


QMS-PS 410 


(PSCRIPT.DRV) 


179 


QMS-PS 800 Plus 


QMS-PS 600 Plus 


(PSCRIPT.DRV) 


180 


QMS-PS 800 


QMS-PS 800 


(PSCRIPT.DRV) 


181 


QMS-PS 810 Turbo 


QMS-PS 810 Turbo 


(PSCRIPT.DRV) 


182 


QMS-PS 610 


QMS-PS 810 


(PSCRIPT.DRV) 


183 


QMS-PS 815 MR 


QMS-PS 815 MR 


(PSCRIPT.DRV) 


184 


QMS-PS 815 


QMS-PS 815 


(PSCRIPT.DRV) 


185 


QMS-PS 820 Turbo 


QMS-PS 820 Turbo 


(PSCRIPT.DRV) 


186 


QMS-PS 620 


QMS-PS 820 


(PSCRIPT.DRV) 


187 


QMS-PS 825 MR 


QMS-PS 825 MR 


(PSCRIPT.DRV) 


188 


QMS-PS 825 


QMS-PS 825 


(PSCRIPT.DRV) 


189 


Qumo ScripTEN 


Qume ScripTEN 


(PSCRIPT.DRV) 


190 


Seiko ColorPoint PS Model 04 


Seiko ColorPoint PS Model 04 


(PSCRIPT.DRV) 
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Keyvalue Description 


Device type 


Driver name 


191 


Seiko CotorPoint PS Model 14 


Seiko CelcrPoint PS Model 14 


(PSCRIPT.DRV) 


192 


Seiko Personal ColorPcInt PS 


Seiko Personal ColorPoint PS 


(PSCRIPT.DRV) 


193 


Silentwriter LC 880XL v50_S 


Silentwriter LC 880XL v50 5 


(PSCRIPT.DRV) 


194 


Silentwriter2 290 v52_0 


Silentwriter2 280 v52 0 


(PSCRIPT.DRV) . 


185 


Silerttwrrter2 Model 80 v52 2 


Silentwriter2 Model 90 v52 2 


(PSCRIPT.DRV) 


186 


Tl 2115 (13 fonts) v47_0 


Tl 2115 (13 fonts) v47 0 


(PSCRIPT.DRV) 


197 


Tl OmniLaser 2108 


Tl OmniLaser 2108 


(PSCRIPT.DRV) 


198 


Tl Omnilaser 2115 


Tl Omnilaser 2115 


(PSCRIPT.DRV) 


199 


Tl microLaser PS17 v_52_1 


Tl microLaser PS17 v_52_1 


(PSCRIPT.DRV) 


200 


Tl microLaser PS35 v_52_1 


Tl microLaser PS35 v_52_1 


(PSCRIPT.DRV) 


201 


Tektronix Phaser tl PX v2 02 


Tektronix Phaser II PX v2 02 


(PSCRIPT.DRV) 


202 


Tektronix Phaser (1 PXi v2010 


Tektronix Phaser II PXi v2010 


(PSCRIPT.DRV) 


203 


Tektronix Phaser III PXi v2010 


Tektronix Phaser III PXi v2010 


(PSCRIPT.DRV) 


204 


Verity per VT*6C0 


Varityper VT-600 


(PSCRIPT.DRV) 


205 


Wang LCS15 FontPlus 


Wang LCS15 FontPlus 


(PSCRIPT.DRV) 


206 


Wang LCS15 


Wang LCS15 


(PSCRIPT.DRV) 



A.6 Special Keywords, Detailed Explanation 

The following part of this appendix will explain some Keywords in detail and 
describe how individual response files and result can be managed. The 
Keywords described are: 

• Include 

• EarlyUserExit 

• UserExit. 

A.6.1 Single Include File Sample 

The response file provides a Keyword called Include. Include makes it possible 
to specify another response file which can be used to include additional 
Keywords or override the current response file's Keywords. Different include 
files could therefore be used for those users who have specific requirements not 
provided by the standard response file. 

The example below provides a sample response file STANDARD. RSP that uses 
the Include Keyword to include a response file called INDIV.RSP. 



BaseFileSystem=2 
Def aul t Pr i nter=50 
DisplayAdapter=0 

W 

If 

II 

FormatPartition=0 

CountryCode=001 

Inc1ude«INDIV.RSP 

M 



II 

Mouse°l 

PrinterPort=l 

REXX=0 



-» 



♦INDIV.RSP 

FonnatPartition=l 

BaseFileSystem=l 

REXX=1 

DisplayAdapter=5 



In the example above the workstation using the include file will differ in the 
sense that its hard disk will be formatted using the HPFS file system. It will use 
a VGA adapter instead of accepting the default and will have REXX installed on 
it. 
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Note 



The entire STANDARD.RSP response file will be processed from beginning to 
end, and only then will the include file, namely INDIV.RSP, be processed. 



A.6.2 Multiple Include Files Example 

The following example shows the functioning of the include statement within the 
response file. It will be explained by discussing the sample. 

The sample consists of seven include files called MOUSE1.INC to M0USE7.INC. 
Each one has one ConfigSysLine with a remark telling which MOUSE(X).INC was 
called and the appropriate mouse function number. 

The content of file MOUSE1.INC is shown below: 



ConfigSysLine=REM mousel Include passed 
mouse°l 



The MOUSE45.INC and MOUSE67.INC have one ConfigSysLine with a remark, 
plus two more Include statements. The contents of file MOUSE45.INC is displayed 
below: 



ConfigSysLine-REM mouse45 include passed 
i ncl ude-niouse4 . i nc 
i ncl ude=nouseS . i nc 



The sample response file is shown below: 



include=KOUSEl.IKC 
i ncl ude=M0USE45 . INC 
i ncl ude-M0USE2 . INC 
incl ude=M0U$E67.INC 
include=M0U$E3.INC 
Mouse=0 



After all data within the basic response file has been interpreted (including the 
Mouse =0 statement in the above sample) the program continues by reading the 
include files in the order of their appearance (MOUSE1.INC, MOUSE45.INC, 
MOUSE2.INC, etc.). Inside the MOUSE45.INC and MOUSE67.INC include files it 
finds more Include statements, which it stores at the end of a program internal 
include table. After MOUSE3.INC has been processed, processing will continue 
by reading the MOUSE4.INC file. Eventually MOUSE7.INC is the last include file 
being read. 

Even though the Mouse =0 statement in the above SAMPLE. RSP file came after 
all include statements it will be interpreted before the include files are handled. 

The following listing shows the essential part of INSTALL.LOG: 
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Processing: 1nclude°M0U$El.INC 
Processing: 1nc1ude°N0USE45.INC 
Processing: include=M0USE2.INC 
Processing: 1nclude°N0USE67.INC 
Processing: 1nc1ude°H0USE3.INC 
Processing: House°Q 

H 

tl 

(( 

Processing: ConfigSysLire=REH mousel Include passed 
Processing: House=l 

Processing: ConflgSysLIne-REM raouse4S Include passed 
Processing: 1nclude=mouse4.1nc 
Processing: 1nclude s mouse5.1nc 
Processing: Conf1gSysL1ne=REH mouse2 Include passed 
Processing: Moused 

Processing: Conf1gSysL1ne=REM mouse67 Include passed 
Processing: 1nc1ude»mouse6.1nc 
Processing: 1nclude=mouse7.1nc 
Processing: Conf1gSysL1ne s REH mouse3 Include passed 
Processing: mouse-3 

Processing: Conf1gSysL1ne=REH mouse4 Include passed 
Processing: mouse-4 

Processing: Conf igSysLine=REM mouses Include passed 
Processing: mouse-5 

Processing: Conf1gSysL1ne s REH mouse6 Include passed 
Processing: mouse-6 

Processing: Conf1gSysL1ne=REM mouse7 Include passed 
Processing: mouse°7 

If 

II 

It 



The following figure visualizes the process explained above. The numbers next 
to the include "boxes" show the order in which the include files are physically 
executed. 
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First Include level Second Include level 



Figure 60. Response File Multiple Include Pattern 



A.6.3 The User Exit Keywords of The Response File 

The response file has two exit keywords: 

• EarlyUserExit 

• UserExit. 

The EarlyUserExit is called at the very beginning before any action is taken upon 
the keywords in the response file. The UserExit is executed at the very end, just 
before the reboot keyword is processed. These user exits can be used to run any 
kind of program or CMD file as long as it is in the path of the PATH statement in 
the CONFIG.SYS. 

The following section will use an example to describe the use of both exits. 

If the target drive is going to be formatted and some files that need to be saved 
were brought into the system after the previous install, they need to be saved 
before the formatting takes place and be restored at the end of the installation 
process. 

For example assume the IBM 4717 MSRE support for the magnetic stripe reader 
was added later and is also needed in the new installation. These files need to 
be backed up and restored at the end of the installation. 

If a normal command procedure called USERSAFE.CMD was used, the response 
file statement used should read: 

EarlyUserExit^USERSAFE.CHD 



136 OS/2 V2.0 Remote Installation 





This command procedure could be used by every workstation, if it resides on the 
server. 

The following example shows how MSRE code can be saved and reinstalled. 

The first example shows the actual copying during the EarlyUserExit CMD 
execution. 



IF EXIST C:\0S2\FI0AUXDD.SYS 


COPY C:\0S2\FI0AUXDD.SYS 


D:\0S2SAV\*.* 


IF EXIST C:\0S2\DLL\MAGCALLS.DLL COPY C:\0S2\DLL\MAGCALLS.Dll 


D; \0S2SAV\DLL\*. * 


IF EXIST C:\0S2\SYSTEH\FI0.HSG 


COPY C:\OS2\SYSTEM\FIO.MSG 


D:\0S2SAV\MSG\*.* 



Instead of D:\OS2SAV a redirected drive on the server could be used. This drive 
has to be a per client drive, to ensure that each client has a unique directory to 
copy to and restore its files from. Otherwise multiple clients could access the 
same redirected drive, thereby disrupting the process of copying, because not 
just the files unique to one client workstation would be in this directory. 

At the end of the installation process the second exit is called which then starts 
a second command procedure, REXX procedure or program. Assuming the 
command procedure was named USERREST.CMD, the syntax for the response 
file statement would be: 

UserExit=USERRE$T.CMD 

Following the above rules the content of this file should be: 



IF EXIST D:\0S2SAV\FIQAUXDD.SYS 


COPY D:\0S2SAV\FI0AUXDD.SYS 


C:\0S2\*.* 


IF EXIST D:\0S2SAV\0LL\HAGCALLS.DLL COPY D:\0S2SAV\DLL\MAGCALLS.DLL C:\0S2\DLL\*.* 


IF EXIST D:\0S2SAV\SYSTEM\FI0.MSG 


COPY D:\0S2SAV\SYSTEM\FI0.MSG 


C:\0S2\SYSTEM\*.* 



By the command "IF EXIST" it makes sure that the copy to/from \OS2SAV only 
takes place, when a specific file exists in that specific directory. 

Note: All files on the target drive for the "saves" in the USERSAFE.CMD should 
be deleted after completion of the copy statement by issuing the following 
command: 

ECHO y | DEL V:\*.* 

assuming V: drive was the redirected drive where the files resided. 

The "ECHO y |" does the rerouting of the "Yes" on the question asked by the DEL 
command when a del *.* is issued. 

If every system on one logical LAN has to be equipped with the same files, 
which are not distributed with OS/2 V2.0, these files can be placed on the server 
in a subdirectory of the distribution image directory (redirected 2: drive) and 
copied during UserExit execution. 

Assuming the MSRE service to be needed on every workstation in one physical 
LAN and residing in a subdirectory called \CUSTDSK, the above file 
(USERREST.CMD) could be used as follows: 
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COPY Z:\CUSTDSK\FIOAUXDD.SYS C:\0S2\*.* 

COPY Z:\CUSTDSK\MAGCALLS.DLL C:\0S2\DLL\*.* 
COPY Z:\COSTDSK\FIO.MSG C:\0S2\MSG\*.* 



Note: By doing this the installation of clients and servers can be extended to 
add new program packages or utilities during installation of the OS/2 base 
operating system. 
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Appendix B. Installation Log 



This appendix shows the INSTALLLOG resulting from an installation upgrading a 
PS/2 Model 70 from OS/2 1.3 to OS/2 2.0 using the sample response file listed in 
A.4, “Sample Response File” on page 130. 



INSTALL.LOG 



Processing default: SourcePath 3 



Installing Operating System/2. 

Model 3 F8 
Submodel 3 09 
ABIOS machine 
Bus Architecture: |1| 
posiofee] = for 
posiD[ei] = leeeei 
PO$ID[02] 3 | elf f | 

POSID[03] 3 |fcff| 

POS I 0 [04] = | df 9f | 

POSIO[05] = |0| 

P0SIDC66] 3 1 0 1 
POSID[07] 3 | e| 

Disk Type: |0| 

Processing response file: Z:\os2se20.rsp 
Processing: A1 ternateAdapter=0 
Processing: BaseFile$ystem 3 2 
Processing: CDR0M=2 
Processing: CountryCode B 001 
Processing: CountryKeyboard=US 
Processing: Defaul tPrinter=0 
Processing: DiagnosticAids 3 l 
Processing: DisplayAdapter»0 
Processing: Documentation®! 

Processing: DOSEnvironment=l 
Processing: DPMI=1 
Processing: ExitOnError=0 
Processing: Fonts®! 

Processing: FormatParti tion a 0 

Processing: Include s x:\indiv.rsp 

Processing: MigrateConfigFiles®0 

Processing: MoreBi tmaps=l 

Processing: Mouse®l 

Processing: MousePort=0 

Processing: Optional FileSystem®l 

Processing: OptionalSy$temUti1ities=4»5,9,13 

Processing: 0S2IniData=/AppName/KeyName/KeyVa1ue/ 

Processing: PrimaryCodePage®l 

Processing: PrinterPort»l 

Processing: ProcessEnvironraent 3 l 

Processing: Progresslndication 3 l 

Processing: Reboo tRequired=0 

Processing: REXX a l 

Processing: Serial Device$upport®l 

Processing: TargetDri ve=d: 

Processing: ToolsAndGames 3 ! 

Processing: ID s O$2SE20 Sample Response File 
Processing: UserExi t=N: \NWINST.CMD 
Processing: Defaul tPrinter=65 

Processing: ConfigSysLine®REM from Included INDIV.RSP 



Processing default: 
Processing default: 
Processing default: 
Processing default: 
Processing default: 
Processing default: 
Processing default: 
Processing default: 



Copy® 

WindowedWIN-OS/2 3 l 

WIN-OS/2Desktop a 0 

Exi sti ngWi ndowsPath® 

ShareDesktopConf i gFi 1 es«l 

EarlyUserExit® 

Extendedlnstall 3 

SeedConfigSysLine® 



Processing default: Version 3 

Greater than 18MB primary partition exists. 

Formatting fixed disk 

Format of fixed disk is complete 

Making directory D:\0S2 

Making directory D:\0S2\DLL 

Making directory D:\0S2\HELP 

Making directory D:\0S2\INSTALL 

Making directory D:\0S2\SYSTEM 

Making directory O:\OS2\SYSTEM\TRACE 

Making directory D:\0S2\B00K 

Making directory D:\0S2\MD0S 

Making directory D:\0S2\MD0S\WIN0S2 

Making directory D:\OS2\MDOS\WINOS2\SYSTEM 

Making directory D:\0S2\BITMAP 

Making directory D:\0S2\APPS 

Making directory D:\0S2\APPS\0LL 

Making directory D:\0S2\HELP\GL0SS 

Making directory D:\0S2\HELP\TUT0RIAL 

Making directory D:\0S2\DRIVERS 

Copying files Z:\Disk_2\UNPACK.EXE -> D:\0S2\UNPACK.EXE 
No Dual Boot installed. 

DISK 2 is being copied to your fixed disk 

D:\0S2\CHKDSK.C0M 

O:\OS2\FORMAT.COM 

D:\0S2\INSTALL\UKPFS.DLL 

D : \ 0S2\ I NSTALL\ BVHVGA.DLL 

D : \ 0S2\ I NSTALL\ DISPLAY.DLL 

D:\0S2\INSTALL\IMAGE.1MI 

D : \ 0S2\ 1 N$TALL\ I NSTALL .INI 

D:\OS2\CLOCK02.SYS 

D:\0S2\IBM2ADSK.ADD 

D:\0S2\IBM2FLPY.ADD 

D:\0S2\IBM2SCSI.ADD 

D:\OS2\KBD02.SYS 

D:\OS2\PRINT02.SYS 

D:\OS2\SCREEN02.SYS 

D:\0S2\IBMINT13.I13 

D:\0S2\0S2DASD.DMD 

D:\0S2\0S2SCSI.DMD 

O:\OS2\TESTCFG.SYS 

D : \ 0S2\ I NSTALIA BVHVGA .DLL 

D : \ 0S2\ I NSTALL\D I SPLAY . DLL 

D:\0S2\INSTALL\IMAGE.INI 

D : \ 0S2\ I N $TALL\ 1NSTALL.INI 

DISK 2 copy is complete 

DISK 3 is being copied to your fixed disk 

D:\0S2\HELP\ANIMAT.AMT 

D:\0S2\DLL\ANMT.DLL 

D:\0S2\ANSI.EXE 

D:\0S2\DLL\ANSICALL.DLL 

D:\0S2\DLL\BDCALLS.DLL 

D:\0S2\DLL\BKSCALLS.DLL 

D:\0S2\DLL\BMSCALLS.DLL 

D:\0S2\B00T.C0M 

D:\0S2\DLL\BUTT0N.DLL 

D:\0S2\DLL\BVHINIT.DLL 

D:\OS2\OLL\BVHMPA.DLL 

D:\0S2\DLL\BVHWNDW.DLL 

D:\0S2\DLL\BVSCALLS.DLL 

D:\0S2\INSTALL\CLEANUP.EXE 

D:\0S2\APPS\CLIP0S2.EXE 

D:\0S2\HELP\CLIPVIEW.HLP 

D:\0S2\CMD.EXE 

D:\0S2\C0MP.C0M 

D:\0S2\C0NVERT.EXE 
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D : \ 0S2\ SY$TEM\ COUNTRY . SYS 

0 :\OS2\ I N$TALL\ BD1NSTAL.EXE 

D:\0S2\HELP\DDINSTAL.HLP 

D:\0S2\DISKCCMP.CGM 

D:\0S2\D1SKC0PY.C0M 

B:\0S2\D0S.SYS 

D:\0S2\BLL\00SCALL1.DLL 

D:\0S2\D0SCALLS.LIB 

D:\0S2\DLL\D0SRFIC0.DLL 

D:\0S2\DLL\DRAG.DLL 

D:\0S2\E.EXE 

D:\0S2\EAUT1L.EXE 

D:\0S2\FIND.EXE 

O:\OS2\DLL\FKA.DLL 

O:\OS2\SYSTEM\HARBERR.EXE 

D:\OS2\HELP.CMD 

D:\0S2\DLL\HELPMGR.DLL 

B:\OS2\HELPHSG.EXE 

D:\0S2\HELP\HMHELP.HLP 

B:\0S2\1NSTALL\HPFS.IFS 

D:\OS2\BLL\HPMGRMRI.OU 

B:\0S2\DLL\IMP.DLL 

B : \ 0S2\ I MSTALL\ I N STALL . EXE 

B:\0S2\HELP\1HSTALL.HLP 

B:\0S2\INSTALL\INSTSHEL.EXE 

0: \ 0S2\ I NSTALL\ I NSTTUTR . EXE 

D : \ 0S2\ HELP\ I NSTTUTR. HLP 

B:\BS2\BLL\KBBCALLS.DLL 

B:\0S2\KEYB.C0H 

B:\OS2\KEYBOARB.BCP 

B:\0S2\M0DE.C0M 

D:\0S2\DLL\K0NCALLS.DLL 

D:\0S2\DLL\K0UCALLS.DLL 

B:\0S2\M0USE.SYS 

D:\0S2\BLL\HSG.BLL 

B:\0S2\BLL\NAMPIPES.DLL 

D:\0S2\DLL\NLS.DLL 

D:\0S2\DLL\NWIAPI.DLL 

D:\0S2\DLL\0S2SM.DLL 

BISK 3 copy is complete 

BISK 4 is being copied to your fixed disk 

D:\0S2\M0RE.C0M 

D:\0S2\DLL\NPXEMLTR.DLL 

B:\0S2\BLL\0S2CHAR.0Lt 

B:\0S2LBR.MSG 

D:\0S2\BI TMAP\ 0S2L0G0. BMP 

B:\0S2\ SYSTEM\ OSOB01 . MSG 

B:\OS2\SYSTEM\OSOB01H.MS6 

D:\OS2\PCLOG1C.SYS 

O:\OS2\OLL\PICV.BLL 

B:\0S2\APPS\DLL\PICVIEW.DLL 

D:\BS2\APPS\PICVIEW.EXE 

B:\0S2\HELP\PICVIEW.HLP 

B:\0S2\DLL\PMCTLS.BLL 

B:\0S2\PMDB.SYS 

D:\0S2\DLL\PMDRAG.DLL 

O:\OS2\OLL\PMGPI.DLL 

D:\0S2\BLL\PMGRE.BLL 

B:\0S2\BLL\PMMLE.DLL 

D:\0S2\BLL\PMSDMR1.DLL 

D:\0S2\BLL\PMSHAPI.DLL 

D:\0S2\BLL\PMSHELL.DLL 

D:\0S2\BLL\PMSHLTKT.BLL 

D:\0S2\0LL\PMSPL.DLL 

B:\0S2\DLL\PMTKT.DLL 

B:\0S2\BLL\PMVBMP.DLL 

D:\OS2\BLL\PMVIOP.DLL 

B:\0S2\BLL\PMWPMRI.DLL 

D:\0S2\P0INTDD.SYS 

B:\0S2\PRINT.C0M 

D:\0S2\BLL\SELECT.DLL 

B:\0S2\BLL\SPL1B.DLL 

DISK 4 copy is complete 

BISK 5 is being copied to your fixed disk 

B:\0S2\DLL\PMWIN.DLL 

D:\0S2\DLL\PMWP.DLL 

B:\0S2\0LL\QUECALLS.DLL 

B:\0S2\REPUCE.EXE 

B:\0S2\BLL\SESM6R.0LL 

B:\OS2\SETBOOT.EXE 

D:\0S2\DLL\S0M.BLL 

B:\OS2\BLL\SPOOLCP.DLL 

B:\0S2\SYSLEVEL.EXE 



B : \ 0S2\ I N STALL\ SYSLEVEL.0S2 

B :\0$2\ INSTALL\ SYSLEVEL.GRE 

D:\0S2\BLL\TUT.DLL 

D:\0S2\0LL\TUTMRI.DLL 

O:\OS2\HELPWIEWH.HLP 

O:\OS2\BLL\VIOCALLS.OLL 

B:\0S2\VI0TBL.BCP 

O:\OS2\BLL\WPCONFIG.DLL 

B:\0S2\ HELP\ GLOSS\ WPGLOSS. HLP 

B:\OS2\XC0PY.EXE 

BISK 5 copy is complete 

BISK 6 is being copied to your fixed disk 

D:\0S2\BLL\EHXBLMRI.DLL 

B:\0S2\HELP\EHXHP.HLP 

B:\0S2\EXTBSKBB.SYS 

B:\0S2\APPS\IC0NEDIT.EXE 

D:\0S2\HELP\IC0NEBIT.HLP 

B:\0S2\DLL\M1NXMRI.DLL 

D:\OS2\OLL\M1NXOBJ.BLL 

O:\OS2\OLL\MIRRaRS.DLL 

B:\0S2\BLL\M1SC.F0N 

B:\BS2\BLL\0ASIS.DLL 

B:\0S2\BLL\PARALLEL.PBR 

B:\0S2\BLL\PMATM.BLL 

O:\OS2\BLL\PHBINB.BLL 

D:\0S2\DLL\PMCHKBSK.DLL 

D:\0S2\PMCHKBSK.EXE 

O:\OS2\APPS\BLL\PMBCTLS.OlL 

B:\OS2\BLL\PMF0RMAT.BLL 

B:\0S2\PMF0RMAT.EXE 

B:\0S2\BLL\PMP1C.DLL 

B:\0S2\BLL\PMPRINT.QPR 

B:\0S2\BLL\PMSHAPIM.DLL 

B:\0S2\PMSHELL.EXE 

D:\0S2\PSCRIPT.SEP 

B:\0S2\RC.EXE 

B:\0S2\RCPP.ERR 

B:\0S2\RCPP.EXE 

B:\0S2\HELP\README 

B:\0S2\INSTALL\RSPDDI.EXE 

D:\0S2\INSTALL\SAMPLE.RSP 

B:\0S2\SAMPLE.SEP 

O:\OS2\DLL\SERIAL.PBR 

B:\0S2\SYSTEM\SPL.MSG 

B:\0S2\SYSTEM\SPLH.MSG 

B:\0S2\SP00L.EXE 

B:\0S2\HELP\START.HLP 

B:\0S2\BLL\STARTHRI.DLL 

D:\0S2\STHR.EXE 

O:\OS2\BLL\SYSFONT.DLL 

D:\OS2\UNOELETE.COM 

O:\OS2\VBISK.SYS 

D:\0S2\VIEW.EXE 

B:\OS2\VIEWO0C.EXE 

B:\0S2\BLL\WPC0NMRI.BLL 

B:\0S2\HELP\WPMSG.HLP 

D:\0S2\DLL\WPPRINT.DLL 

D:\0S2\BLL\WPPWNBRV.0LL 

D:\OS2\SYSTEM\OEV002.MSG 

B:\0S2\SYSTEM\UCBFS.MSG 

DISK 6 copy is complete 

BISK 7 is being copied to your fixed disk 

B:\0S2\BLL\TIMES.VGA 

D:\0S2\APPS\CARBSYM.F0N 

O:\OS2\APPS\ BLL\KLONBGA.DLL 

B:\0S2\APPS\KL0NBIKE.EXE 

O:\OS2\HELP\KLONDIKE.HLP 

B:\0S2\APPS\BLL\SCRAMBLE.BLL 

B:\0S2\APPS\SCRAMBLE.EXE 

B:\0S2\HELP\SCRAMBLE.HLP 

B:\0S2\APPS\ BLL\SCRCATS . DLL 

B : \ 0S2\ APPS\0LL\SCRL060 . DLL 

D:\0S2\APPS\DLL\CHESSAI .DLL 

D:\OS2\APPS\OS2CHESS.BIN 

D : \ 0S2\APPS\ 0S2CHESS . EXE 

D:\0S2\HELP\0S2CHESS.HLP 

D:\0S2\8514.RC 

D:\0S2\8514M.RC 

D:\0S2\C6A.RC 

D:\0S2\EGA.RC 

D:\0S2\INI.RC 

D:\0S2\INISYS.RC 

D:\0S2\MAKEIN1.EXE 



140 OS/2 V2.0 Remote Installation 




D:\0S2\H0VESPL.EXE 

D:\0S2\0S2 13. RC 

D:\0S2\0S2~20.RC 

D:\0S2\PLASMA.RC 

D :\0S2\ I NSTALL\RSPI NST . EXE 

D:\0S2\0LL\SHPIINST.DLL 

O:\OS2\UPIHI.RC 

D:\0S2\VGA.RC 

D:\0S2\VGAM.RC 

D:\0S2\WIN 30. RC 

D:\0S2\XGa7rC 

D : \0S2\MD0S\WI N0$2\ SY$TEM\ SYMBOLE . FON 

D : \ 0S2\MD0S\W I N0$2\ SYSTEM\ ROMAN . FON 

DISK 7 copy is complete 

01 SK 8 is being copied to your fixed disk 

D:\0S2\DLL\TIMESNRM.PSF 

D:\0S2\MD0S\VEMM.SYS 

D:\0S2\MD0S\VWIN.SYS 

D:\0S2\CREATE0D.EXE 

D:\0S2\L0G.SYS 

D:\0S2\ SYSTEM\ LOGDAEM .EXE 

D:\0S2\PATCH.EXE 

D:\0S2\PSTAT.EXE 

D:\0S2\0LL\SYSL0G.DLL 

D:\OS2\SYSLOG.EXE 

O:\OS2\HELP\SYSLOGH.HLP 

D:\0S2\$YSL0GPM.EXE 

D:\0S2\SYSTEM\TRACE\SYSTEM.TDF 

O:\OS2\SYSTEM\TRACE\SYSTEM.TFF 

O:\OS2\TRACE.EXE 

D:\0S2\0LL\TRACEFMT.DLL 

D:\0S2\TRACEFMT.EXE 

D:\0S2\ HELP\ TRACEFMT . HLP 

D:\0S2\BITMAP\AAAAA.EXE 

D:\0S2\BI TMAP\AAAAA. MET 

D:\0S2\BITMAP\LIGHTH0U.VGA 

D:\0S2\DRI VERS\ 152XA0D . OOP 

D : \ 0S2\ DR I VERS\ 152XPRES . EXE 

D : \ 0S2\ DRI VERS\ 154XADD . ODP 

D : \ 0S2\ DR I VERS\ 154XPRES . EXE 

D:\0S2\DRIVERS\154XPRES.EXE 

D : \ 0S2\ DR I VERS\ 164XADD . DDP 

D : \ 0S2\ DRI VERS\ 164XPRES . EXE 

D : \ 0S2\ DR I VERS\ 174XADD . DDP 

D:\0S2\DRIVERS\174XPRES.EXE 

D:\0S2\DRIVERS\AHA152X.ADD 

D:\0S2\DRIVERS\AHA154X.ADD 

D:\0S2\DRIVERS\AHA164X.ADD 

D : \ 0S2\ DR I VER$\ AHA 174X . ADD 

D:\OS2\DRIVERS\FD16-760.ADD 

D:\OS2\DRIVERS\FD16-700.DDP 

0: \0S2\ DR] VERS\ FD16- 700. EXE 

0 : \ 0S2\ DR I VERS\ FD850 I BM . ADD 

D : \ 0S2\ DRIVERSX FD850 I BM . DDP 

D : \ 0S2\ DRIVERSX FD850 I BM . EXE 

D : \ 0S2\ DR I VERS\ FD8XX . ADO 

D:\0S2\DRIVERS\FD8XX.DDP 

D:\0S2\DR1VERS\FD8XX.EXE 

D:\0S2\MD0S\W1N0S2\SYSTEM\M0DERN.F0N 

DISK 8 copy is complete 

DISK 9 is being copied to your fixed disk 

D:\0S2\B00K\CMDREF.1NF 

D:\0S2\SYSTEM\REX.MSG 

D:\0S2\SYSTEM\REXH.MSG 

D:\0S2\DLL\REXX.DLL 

D:\0S2\DLL\REXXAPI.DLL 

D:\0S2\DLL\REXXINIT.DLL 

D:\0S2\REXXTRY.CMD 

D:\0S2\DLL\REXXUTIL.DLL 

D:\0S2\RXQUEUE.EXE 

D:\OS2\RXSUBCOM.EXE 

D:\0S2\C0M.SYS 

D:\0S2\DLL\BVHSVGA.DLL 

D:\0S2\DLL\BVHVGA.DLL 

D:\0S2\SVGA.EXE 

D:\0S2\DLL\VGA.DLL 

D:\0S2\MD0S\WIN0S2\SYSTEM\SCRIPT.F0N 

DISK 9 copy is complete 

OISK 10 is being copied to your fixed disk 

D:\0S2\MD0S\WIN0S2\SYSTEM\ATM16.DLL 

D:\0S2\MD0S\WIN0S2\ATMCNTRL.EXE 

D:\0S2\MD0S\WIN0S2\SYSTEM\ATMSYS.DRV 

D:\OS2\MDOS\WINOS2\SYSTEM\C6A40WOA.FON 



D : \ 0S2\ MDOS\W I N0S2\ SY STEM\ CGA88W0A . FON 

D: \ 0S2\MD0S\W I N0S2\ CLI PBRD. HLP 

D: \ 0$2\MD0S\W I N0S2\ CLI PW0S2. EXE 

D: \ 0S2\MD0S\W I N0$2\ CLOCK. EXE 

D:\OS2\MDOS\WINOS2\SYSTEM\COMM.DRV 

D:\0S2\MD0S\WIN0S2\C0NTR0L.EXE 

D:\0S2\MD0S\WIN0S2\C0NTR0L.HLP 

D:\0S2\MD0S\WIN0S2\DDEAGENT.EXE 

D:\0S2\MD0S\WIN0S2\DIGITAL.F0N 

D : \ OS2XMOOSXWI N0S2\SYSTEM\ DRVMAP . I NF 

D : \ 0S2\MD0S\W I N0$2\$YSTEM\ EGA40W0A . FON 

0:\ 0S2\MD0S\W I NOS2\SYSTEM\EGA80WOA . FON 

D:\OS2\MDOS\WINOS2\F I XWP. EXE 

D:\0S2\MD0S\W1N0S2\SYSTEM\GDI.EXE 

D:\0S2\MD0S\W1N0S2\G0PM.EXE 

D:\0S2\MD0S\WIN0S2\SY$TEM\ HERCULES. DRV 

D:\0S2\MD0S\WIN0S2\SYSTEM\KBD0LI.DRV 

D : \ 0S2\MD0S\ W I N0S2\$YSTEM\ KERNEL . EXE 

D : \ 0S2\MD0S\ W I N0S2\ SYSTEM\ KEYBOARD . DRV 

D : \ 0S2\MD0S\ W I N0S2\ SYSTEM\ LZEXPAND. DLL 

D:\0S2\MD0S\WIN0S2\SYSTEM\M0USE.DRV 

D:\0S2\MD0S\WIN0S2\SYSTEM\MSNET.DRV 

D:\OS2\MDOS\WINOS2\SYSTEM\NOMOUSE.DRV 

D: \ 0S2\MD0S\W I N0S2\SYSTEM\ 0S2K286.EXE 

D:\0S2\MD0S\WIN0S2\SYSTEM\PLASMA.DRV 

D:\0S2\PMDDE.EXE 

D:\OS2\MDOS\WINOS2\PRINTMAN.EXE 

D:\0S2\MD0S\WI N0S2XPRI NTMAN . HLP 

D:\0S2\MD0S\W1N0S2\PR0GMAN.EXE 

D:\0S2\MD0S\WI N0S2\PR0GMAN . HLP 

D : \ 0S2\MD0S\WI N0S2\README . ATM 

D : \ 0S2\MD0S\WI N0S2\SETUP . EXE 

D: \ 0$2\MD0S\WI N0S2\SETUP. HLP 

D:\0S2\MD0S\WIN0S2\SYSTEM\SETUP.INF 

D:\OS2\MDOS\WINOS2\SYSTEM\SF4019.EXE 

D : \ 0S2\ MD0S\ W I N 0S2\ S YSTEM\ SOUND . DRV 

D : \ 0S2\ MD0S\ W I N0S2\ SYSTEM\ SYSTEM . DRV 

D :\0$2\MD0S\WI N0S2\TASKMAN . EXE 

D:\0S2\MD0S\WIN0S2\UNFIXWP.EXE 

D : \ 0S2XMD0SXWI N0S2\ SY STEM\ USER . EXE 

D : \ 0S2\MD0S\W 1 N0S2\ SY STEM\ V7VGA . DRV 

D : \ 0S2\MD0S\WI N0S2\ VDMSRVR . EXE 

D:\OS2\MDOS\WINOS2\SYSTEM\VGA850.FON 

D : \ 0S2\MD0S\W I N0S2\ SY STEM\ VGA860 . FON 

D:\0S2\M00S\WJN0S2\SYSTEM\VGA861.F0N 

D:\ 0S2\MD0$\WI N0S2\SY$TEM\ VGA863. FON 

D:\0S2\MD0S\W1N0S2\SYSTEM\V6A865.F0N 

D:\0S2\MD0S\W1N0S2\WIN . COM 

D:\0S2\MD0S\WIN0S2\SYSTEM\WIN87EM.DLL 

O:\OS2\MDOS\WINOS2\WINHELP.EXE 

D : X 0S2\ MDOSX WIN 0S2\ W I NHELP . HLP 

D : \0S2\MD0S\WI N0S2\ W 1 N0S2 . COM 

D:\0S2\MD0S\WIN0S2\WIN0S2. ICO 

D:\0S2\MD0S\WIN0S2\WINSHELD.EXE 

D:\OS2\MDOS\WINOS2\SYSTEM\WINSMSG.DLL 

D:\0S2\MD0S\WIN0S2\WINVER.EXE 

D:\0S2\MD0S\WIN0S2\W0S2ACCE.GRP 

D : \ 0S2XMD0SXWI N0S2\ W0S2MA1 N . GRP 

D:\0S2\MD0S\WIN0S2\SYSTEM\XLAT856.BIN 

D:\OS2\MDOS\WINOS2\SYSTEM\XLAT860.BIN 

D:\0S2\MD0S\WIN0S2\SYSTEM\XLAT861.BIN 

D:\0S2\MD0S\WIN0S2\SYSTEM\XLAT863.BIN 

D:\OS2\MDOS\WINOS2\SYSTEM\XLAT865.BIN 

D:\0S2\MD0S\WIN0S2\ATM.INI 

DISK 10 copy is complete 

DISK 11 is being copied to your fixed disk 

D : \ 0S2\ APPS\ 0LL\ PMSEEK . DLL 

D:\0S2\APPS\PMSEEK.EXE 

D:\0S2\HELP\PMSEEK.HLP 

D:\0S2\MD0S\ANSI.SYS 

D:\0S2\MD0S\APPEND.EXE 

D:\0S2\MD0S\ASSIGN.C0M 

D:\0S2\MD0S\BASIC.C0M 

O:\OS2\MDOS\BASICA.COM 

D:\0S2\MD0S\C0MMAND.C0M 

D : \ 0S2\ 1 N$TALL\ DBTA6S . DAT 

D:\0S2X INSTALLX DATABASE . DAT 

D:\0S2\MD0S\DEBUG.EXE 

D:\OS2\MDOS\DOSKEY.COM 

D:\0S2\MD0S\D0SKRNL 

D:\OS2\MDOS\EDLIN.COM 

D:\0S2\MD0S\EGA.SYS 

D:\0S2\MD0S\EMM386.SYS 
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D:\0S2\MD0S\FSACCESS.EXE 

D:\0S2\MD0S\FSFILTER.SYS 

D:\0S2\MD0S\GRAFTABL.C0M 

D:\0S2\MD0S\HELP.BAT 

D:\0S2\MD0S\HIMEM.SYS 

D:\OS2\MDOS\JOIN.EXE 

D:\0S2\MD0S\LPTDD.SYS 

D:\0S2\MDQS\C0MDD.SYS 

D:\0S2\MD0S\MEM.EXE 

O:\OS2\IN STALL\M I GRATE . EXE 

D:\0S2\HELP\MIGRATE.HLP 

0 : \ 0S2\ MDOS\MORTGAGE. BAS 

O:\OS2\MBOS\MOUSE.COH 

D:\0S2\MD0S\QBASIC.EXE 

D:\OS2\MDOS\QBASIC.HLP 

D : \ 0S2\ MOOS\ SETCOM40 . EXE 

D:\0S2\MD0S\SUBST.EXE 

D:\0S2\MD0S\V8514A.SYS 

D:\0S2\MD0S\VBI0S.SYS 

D:\0S2\MD0S\VCDR0M.SYS 

D:\OS2\MBOS\VCGA.SYS 

D:\0S2\MD0S\VCM0S.SYS 

D:\0S2\MB0S\VC0M.SYS 

D:\OS2\MDOS\VDMAAT.SYS 

D : \ 0S2\ MBOS\ VDMAPS2 . SYS 

D:\OS2\MBOS\VDSK.SYS 

D:\0S2\MD0S\VEGA.SYS 

D:\OS2\MBOS\VFLPY.SYS 

D:\0S2\MD0S\VKBD.SYS 

D:\0S2\MD0S\VLPT.SYS 

D:\0S2\MD0S\VMDISK.EXE 

D:\0S2\MD0S\VM0N0.SYS 

B:\0S2\M00S\VM0USE.SYS 

D:\0S2\MD0S\VNPX.SYS 

D:\0S2\MB0S\VPIC.SYS 

D:\0S2\MD0S\VTIMER.SYS 

O:\OS2\HBOS\VVGA.SYS 

D:\OS2\HDOS\VXGA.SYS 

D:\OS2\MBOSWDPX.SYS 

O:\OS2\I MST ALL\ PARSEDB . EXE 

D:\0S2\ INSTALL\DATABASE.TXT 

D:\OS2\MDOS\VTOUCH.COM 

D:\0S2\MB0S\VSVGA.SYS 

D:\0S2\MB0S\VXMS.SYS 

DISK 11 copy is complete 

DISK 12 is being copied to your fixed disk 

D:\0S2\DLL\TUTDLL.DLL 

D:\0S2\TUT0R1AL.EXE 

D:\0S2\HELP\TUT0RIAL\TUT0RIAL.HLP 

D : \ 0S2\ APPS\ PHDALARM . EXE 

D:\0S2\APPS\PMDCALC.EXE 

D:\0S2\APPS\PKDCALEN . EXE 

D: \ 0S2\APPS\ PMBOARC . EXE 

D : \0S2\APPS\PMBDI ARY . EXE 

D:\0S2\APPS\PMDIARY.$$A 

B : \ 0S2\APPS\ BLL\ PMD 1 ARY . DLL 

D:\0S2\HELP\PMDIARY.HLP 

D:\0S2\APPS\BLL\PMD1ARYF.DLL 

D:\0S2\APPS\PMBLIST.EXE 

D:\0S2\APPS\PMDM0NTH. EXE 

D:\0S2\APPS\PMBN0TE.EXE 

D:\0S2\APPS\PMBTARC.EXE 

D:\0S2\APPS\PMBT0B0.EXE 

D:\0S2\APPS\PMDTUNE.EXE 

D:\0S2\APPS\PMMBASE.EXE 

D:\0S2\APPS\PMSPREAB.EXE 

D : \ 0S2\APPS\ BLL\ PMST1CKD.BLL 

D : \ 0S2\ APPS\ PMST I CKY . EXE 

D:\0S2\APPS\REVERSI.EXE 

D : \ 0S2\ HELP\ REVERS I . HLP 

D:\0S2\APPS\0LL\NEK0.DLL 

D:\0S2\APPS\NEK0.EXE 

D:\0S2\HELP\NEK0.HLP 

D:\0S2\APPS\PULSE.EXE 

D:\0S2\HELP\PULSE.HLP 

D:\0S2\MB0S\WIM0S2\SYSTEM\VGA.BRV 

D:\0S2\MD0S\WIN0S2\SYSTEM\VGASYS.FCN 

D:\OS2\MDOS\MIKOS2\SYSTEM\VGAOEM.FON 

D:\0S2\MD0S\WIN0S2\SYSTEH\V6AFIX.F0N 

D:\OS2\MBOS\MINOS2\SYSTEH\VGAMONO.ORV 

D:\OS2\MBOS\MINOS2\SYSTEM\SWINVGA.DRV 

D:\OS2\MBOS\MIROS2\SYSTEM\HELVE.FON 

DISK 12 copy is complete 



DISK 13 is being copied to your fixed disk 

D:\OS2\DLL\COURIER.PSF 

D:\OS2\FDISK.COM 

D:\0S2\BLL\FDISKPM.DLL 

D:\0S2\FBISKPM.EXE 

D:\0S2\HELP\FDISKPMH.HLP 

D:\0S2\SETB00T.EXE 

D:\OS2\HELP\ACOISIO.HLP 

D:\0S2\APPS\ACSACDI.DAT 

D:\0S2\HELP\ANSI364.HLP 

D:\0S2\HELP\ANSIIBM.HLP 

D:\OS2\APPS\DLL\CTLSACDI.BLL 

D:\0S2\APPS\CTLSACDI.EXE 

D:\0S2\APPS\CUST0M.MDB 

D:\OS2\HELP\IBM31011.HLP 

D:\0S2\HELP\IBM31612.HLP 

D:\0S2\HELP\IBMSI0.HLP 

D:\0S2\APPS\DLL\ 0ACDIS10.DLL 

D:\0S2\APPS\0LL\0ANS1 .DLL 

D:\0S2\APPS\DLL\0ANSI364.BLL 

D:\0S2\ APPS\ DLL\OCKAR.DLL 

D:\0S2\APPS\DLL\0CM.BLL 

D:\OS2\APPS\DLL\OCOLOR.DLL 

D:\0S2\APPS\DLL\ OCSHELL . DLL 

D:\0S2\APPS\0LL\0DBM.DLL 

D:\0S2\APPS\0LL\ OFMTC . DLL 

D:\0S2\APPS\0LL\0IBM1X.DLL 

D:\OS2\APPS\DLL\OIBM2X.DLL 

D:\OS2\APPS\DLL\OKB.DLL 

D:\0S2\APPS\DLL\0KBC.DLL 

D:\0S2\APPS\DLL\0KERMIT.DLL 

D:\OS2\APPS\DLL\OLPTIO.DLL 

D:\0S2\APPS\DLL\0MCT.DLL 

D:\0S2\APPS\DLL\ OMRKCPY . DLL 

D:\0S2\APPS\DLL\ OPCF . DLL 

D:\0S2\APPS\DLL\0PM.DLL 

O:\OS2\APPS\DLL\OPROFILE.DLL 

D:\OS2\APPS\ BLL\ORSHELL . DLL 

D:\0S2\APPS\DLL\0SCH.DLL 

D:\0S2\APPS\DLL\0SI0.DLL 

D : \ 0S2\ APPS\ BLL\ OSOFT . DLL 

D:\OS2\APPS\BLL\OTEK.OLL 

D:\0S2\APPS\DLL\0TTY.DLL 

D:\0S2\APPS\BLL\0VI0.DLL 

D:\0S2\APPS\DLL\0VM.DLL 

D:\OS2\APPS\OLL\OVT.DLL 

D:\OS2\APPS\DLL\OXMODEM.DLL 

D:\OS2\APPS\DLL\OXRM.DLL 

D:\OS2\APPS\DLL\SACOI .DLL 

D:\OS2\SYSTEM\SACDI.MSG 

D:\0S2\APPS\DLL\SAREXEC.DLL 

D:\OS2\APPS\SASYNCDA.SYS 

D:\0S2\APPS\SASYNCBB.SYS 

D:\0S2\APPS\S0FTERM.EXE 

D:\0S2\HELP\S0FTERM.HLP 

D:\0S2\HELP\TTY.HLP 

O:\OS2\HELP\VTTERM.HLP 

D:\0S2\HELP\XRH.HLP 

D:\OS2\DLL\WPPRTHRI.DLL 

D:\0S2\CDFS.IFS 

D:\0S2\CDR0M.SYS 

D:\0S2\DLL\UCDFS.DLL 

D : \ 0S2\MD0S\W I N 0S2\ SYSTEM\ COURE . FON 

DISK 13 copy is complete 

DISK 14 is being copied to your fixed disk 

D:\OS2\BO0K\REXX.INF 

D:\OS2\OLL\HELV.VGA 

D:\0S2\0LL\PMREXX.DLL 

D:\0S2\PMREXX.EXE 

D:\0S2\HELP\PMREXX.HLP 

D:\0S2\APPS\FASHI0N.DAT 

D:\0S2\APPS\FASHI0N.GRF 

O:\OS2\APPS\GREEN.DAT 

D:\0S2\APPS\GREEN.GRF 

D:\0S2\APPS\INVEST.DAT 

D:\0S2\APPS\INVEST.GRF 

D : \ 0S2\ APPS\ DLL\MGXL I B . DLL 

D:\0S2\APPS\DLL\HGXVBM. DLL 

D:\0S2\APPS\PMCHART.EXE 

D:\0S2\HELP\PMCHART.HLP 

D:\0S2\APPS\DLL\PMFID.DLL 

D:\0S2\MD0SWDPMI.SYS 

D:\0S2\MD0S\WIN0S2\WIN.INI 
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O:\OS2\KBOS\MINOS2\SYSTEH. INI 

O:\OS2\KBOS\NINOS2\GONTROL. INI 

O:\OS2\MBOS\HINOS2\PROGMAN. INI 

DISK 14 copy Is complete 

DISK IS Is being copied to your fixed disk 

D:\0S2\0LL\C0URIER.V6A 

D:\OS2\DLL\SYSMONO.FON 

D:\0S2\DLL\HELVETIC.PSF 

D:\0S2\TREE.C0H 

D:\0S2\DLL\CPISPFPC.DLL 

D:\0S2\INSTALL\0HPC.EXE 

D:\0S2\0LL\DTH.DLL 

D:\0S2\0a\INACALL.BLL 

D:\0S2\INSTAll\INSTAID.CNF 

D:\0S2\INSTALL\ I NSTAIO. EXE 

D:\0S2\ I NSTALL\ I NSTAIO. LIB 

D:\OS2\INSTALL\INSTAID.PRO 

O:\OS2\INSTALL\INSTAIDE.EXE 

O:\OS2\lNSTALL\ISPD.HS6 

O:\OS2\INSTALL\ISPM.KS6 

O:\OS2\BLL\ STXTDKPC . DLL 

O:\OS2\APPS\BOX.EX 

O:\OS2\APPS\BRAH.EX 

D:\0S2\APPS\E3EMUL.EX 

D:\0S2\APPS\EPH.EX 

D:\0S2\APPS\EPH.EXE 

D:\0S2\HELP\EPM.HLP 

D:\OS2\APPS\EPMHELP.0HL 

D:\OS2\APPS\EPMLEX.EX 

D: \0S2\APPS\DLL\ETKE556.DLL 



O:\OS2\APPS\BLL\ETKR558.DLL 

O:\OS2\APPS\BLL\ETKTHNK.DLL 

D:\0S2\APPS\EXTRA.EX 

D:\0S2\APPS\6ET.EX 

D:\0S2\APPS\HELP.EX 

D:\0S2\APPS\PUT.EX 

D:\0S2\APPS\JI6SAH.EXE 

D:\0S2\KELP\J1GSAW.HLP 

D:\0S2\CACHE.EXE 

D:\0S2\HPFS.IFS 

D:\OS2\OLL\STARTLW.DLL 

O:\OS2\DLL\UHPFS.DLL 

D:\OS2\HBOS\HINOS2\SYSTEN\THSRE.FON 

DISK 15 copy Is conplete 

DISK 6 Is being copied to your fixed disk 

D:\0S2\HELP\NPHELP.HLP 

O:\OS2\HELP\KPINDEX.HLP 

DISK 6 copy 1$ conplete 

Systen files are being copied to your fixed disk 

O:\OS2KRNLI 

D:\OS2LDR 

O:\OS2LBR.HSG 

Systen file transfer 1$ conplete 
CreateConflgSys: (\CCNFIG.SYS) rc • 6 
CreateAutoexec: (\AUTOEXEC.BAT) rc * 8 
Copying files Z:\PKDD 1MBMNULL.DRV 
Copying files Z:\IWKfl\PSCRIPT.DRV 
Installation Is conplete 
Executing prograa N:\NHINST.CMD 



Appendix B. Installation Log 



143 




144 OS/2 V2.0 Remote Installation 




Appendix C. Partitioning of Physical Disks 



C.1 Partitioning Physical Disks 

This section provides information on the management of physical disks by an 
operating system. 

Refer to the publications below for detailed information on disk partitioning: 

• OS/2 V2.0 Command Reference, Online information 

• OS/2 V2.0 Operating System Installation Guide 

• OS/2 V2.0 Operating System Information and Planning Guide, G360-2650 

• OS/2 V2.0 Volume 1: Control Program, GG24-3730. 

C.1.1 Disk Partitioning under OS/2 VI .3 

The following three options are available when partitioning fixed disks using an 
OS/2 VI. 3 operating system: 

1. Create primary partition 

This partition becomes the first logical drive (C:) for the operating system. 

2. Create extended partition 

This provides the ability for the partition to be divided into one or several 
logical drives. 

3. Create logical drives. 

These logical drives (for example D:, E:, F:) can now be accessed by the 
operating system. 

A second primary partition could be created but can only be accessed by a 
operating system other than DOS or OS/2. 

C.1 .1 .1 Resizing of Logical Drives 

In the following example logical drives D: and E: are reduced in size in order to 
create a new logical drive F:. 



Disk 170 MB 






Primary partition 


C: 


40 MB 


Secondary partition 




170 - 40 = 130 MB 


Logical drive 1 


D: 


70 MB 


Logical drive 2 


E: 


60 MB 



The user has to delete logical drive E: first. Then logical drive D: can be deleted. 
Upon completion logical drives can be created in the order D:, E: and F:. 
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Disk 170 MB 






Primary partition 


C: 


40 MB 


Secondary partition 




170 - 40 = 130 MB 


Logical drive 1 


D: 


40 MB 


Logical drive 2 


E: 


40 MB 


Logical drive 3 


F: 


50 MB 



Although logical drives D:, E: and F: have to be reformatted, the data on drive C: 
can still be accessed. If however the size of C: needs to be changed, all data 
on this disk will be lost. 

Note: In the above example the addition of logical drive F: will cause the data 
on drives E: and D: to be corrupted. 

C.1.2 Multiple Fixed Disks 

The following table shows the hardware specifications when using multiple fixed 
disks, under OS/2. 



Table 8. Hardware Specifications 




OS/2 1.2 

System 

Max. 


OS/2 1.3 

System 

Max. 


OS/2 2.0 

System 

Max. 


Fixed Disk Drives Supported 


15 


24 


24 


Logical Drives Supported 


26 


26 


26 


Maximum Disk Partition Size 


2GB 


2GB 


>2GB 


Maxi.# of Primary Part./Drive 


1 


1 


4 


Maximum # of Partitions/Drive 


16 


16 


24 


Diskette Drives Supported 


3 


3 


3 



The diagram below shows how drive letters are assigned when multiple fixed 
disk are used. 
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Figure 61. Multiple Disk Drive Letter Assignment 

• Starting with the primary partition of the first physical disk, and followed by 
the primary partition on the second disk, etc, these partitions are named C:, 
D:, etc. 

• Next are the logical drives on the first physical disk. They will use the next 
letters in the alphabet (for example E: and F:) 

• Then the logical drives on the second physical disk (for example G:, H: and 
I:), etc. 

If a third physical disk was added all of the logical drive names will change, 
because the new primary partition created will take over the name of the first 
logical drive, namely E:, thereby shifting the drive letters of all logical drives 
forward by one letter (for example E: becomes F:, F: becomes G: etc.). 

It is important to note that, if an extra physical disk is added, all the information 
in PATH, DPATH, LIBPATH etc. must be updated, because different drive letters 
have been assigned. 

C.1.3 Enhanced Functionality of OS/2 V2.0 

Listed below are the enhanced functions of OS/2 V2.0: 

• The ability to have several primary partitions on the same physical disk. 

It is important to note that only one primary partition on the same disk can 
be accessed at any one time. 

• The OS/2 V2.0 operating system can be installed on any of the primary 
partitions or logical drives, thereby allowing one physical disk to have more 
than one operating system. 

• Boot Manager is a new feature that allows the user to have more than one 
operating system resident on his workstation, and the option to decide which 
operating system to boot from initially. 
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The Boot Manager must reside on the first physical disk. The Boot Manager 
is installed by using FDISK and is managed by either FDISK or the new 
SETBOOT command. For details see OS/2 V2.0 Command Reference, Online 
information. 

• Enhancements to the FDISK function allows the deletion of any partition or 
logical drive without destroying data not related to this partition or logical 
drive. 

The space created by deleting a partition or logical drive can now be reused 
to create any type of partition or logical drive of the same size or less. This 
new partition can be created at the beginning or the end of the free space. 

Only one operating system can be active at one time. Operating systems 
installed on primary partitions on different physical disks remain accessible. 

For example OS/2 VI. 3 is on the first disk (drive C:) and OS/2 V2.0 is on the 
second disk (drive D:). The Boot Manager can start either operating system 
which in turn will have access to the other operating systems files and 
directories. 

The following figure shows the new disk organization. 
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Primary Partition 3 / OS 2 Data 



Logical Partlon 1 / Shared Data 



Logical Partlon 2 / Shared Data 
Logical Partlon 3 / Shared Data 
Logical Partlon N / Shared Data 

SB. Sy»t»m Partition (PS/2-0X) / 



Primary Partition 1 



Primary Partition 2 



Primary Partition 3 



I Partlon 1 / Shared Data / 



O Logical Portion 2 / Shared Data^ / 

- - — S — 

Logical Partlon 3 / Shared Data ^ 



j§ Logical Portion N / Shared Data 

s 



Figure 62. Usage of Boot Manager in OS/2 V2.0 



C.1.4 Restrictions 

When using the Boot Manager option with several operating systems residing on 
the same workstation, the following restrictions apply: 

• DOS: Must reside on first primary partition of the first physical disk. If the 
DOS version is earlier than 4.0, this partition can not be greater than 32 MB. 

• OS/2 V1.3: Must reside on a primary partition of the first physical disk. 

• Boot Manager: Must reside on a primary partition of the first physical disk. 

it is impossible to add a Boot Manager primary partition on the first physical disk 
without the new FDISK program. Furthermore one partition or logical drive needs 
to be deleted to free up space for the Boot Manager partition. This action 
destroys the data located on that part of the disk. 
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Appendix D. Description of FDISK functions 



D.1 The Fixed Disk Utility Program (FDISK) 

The Fixed Disk Utility Program (FDISK) provides functions such as creation of 
partitions or logical drives, their deletion and/or making them startable, all of 
which are needed to make logical drives accessible for data and programs. 

There are two types of FDISK programs, each providing the same functions: 

• FDISK for OS/2 V2.0 or DOS utilizing its own user interface and callable from 
a batch file (.CMD). 

This program has a full screen non-PM interface because it is used in 
several environments where PM is not available. 

• FDISKPM for OS/2 under the control of Presentation Manager. 

It is used to update disk environments on a live operating system. 



D.1.1 Description of FDISK for OS/2 V2.0 

FDISK for OS/2 V2.0 enables the user to partition the hard disks and specify Boot 
Manager support options. 

The following figure is discussed in detail below. 



FDISK 



Disk 1 



Volume Information 

Name Status Access FS Type MBytes 



00010109 Startable C: Primary FAT 50 

00010132 None D: Logical FAT 8 



The FDISK screen has five columns containing specific information about the 
partitions that exist on the system hard disk. Each hard disk is represented by a 
number at the top of the FDISK screen. When you select a hard disk, its partition 
information is displayed in the window. Partitions are either primary partitions 
or logical drives within an extended partition. Any free space (space within the 
hard disk that is available for more partitions) is also displayed in the window. 
This information includes: 

• Name 

Is the name that has been assigned to any primary partition or logical drive 
to be displayed on the Boot Manager menu. This name is specified using 
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the "Add to Boot Manager" menu option and can be changed by using the 
"Change Partition Name" option. 

• Status 

Indicates if a partition is Installable, Bootable, Startable or none of the above. 

If set Installable, the respective partition will be used as the target for 
continuing the OS/2 install. 

If set Bootable, the respective partition is displayed on the Boot Manager 
menu when the system is restarted. 

If set Startable, the system restarts directly from this partition and will be 

Installable. 

These options are available for primary partitions only. Remember one of the 
primary partitions must be set Startable for the system to restart 
successfully. 

• Access 

Specifies if a partition is accessible. The letter in the column indicates that 
the partition is accessible. This column also indicates if the partition is a 
primary partition or a logical drive within the extended partition. 

• FS Type 

Indicates the type of file system on the partition. Any partitions that have not 
been formatted will be displayed as Unformatted. Any area on the hard disk 
not assigned to a partition will be displayed as “Free Space.” 

• MBytes 

Indicates the size in megabytes of the partition or “Free Space.” 

To modify a disk setup, select the partition or Free Space entry on the FDISK 
screen and then press Enter to display the "Options" pull-down. 

Use the tab key to activate the Disk selection. 

D.1.2 Functions on "Options" Pull-Down Menu of FDISK 

The following functions are available on the "Options" pull down menu of FDISK: 

• Install Boot Manager 

Creation of Boot Manager partition and loading the Boot Manager program. 

• Create Partition- 

Creation of primary or secondary partition or logical drive. 

• Add to Boot Manager menu... 

New partition bootable, selectable from Boot Manager menu. 

• Change Partition Name- 

Change name of partition in Boot Manager menu. 

• Assign C: Partition 

In case of multiple primary partitions, selection of default <C:) partition in the 
Boot Manager menu. 

• Set Startup Values... 

Specify startup values such as a default partition, startup menu timeout, or 
mode for the startup menu. 

• Remove from Boot Manager menu 

• Delete Partition 
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• Set Installable 

This partition is ready to receive a new operating system. 

• Make Startable 

Use this choice to set a primary partition as the direct restart target. For 
Boot Manager support, the Boot Manager partition must be set to Startable. 

| Note 

All of the functions that are updating the size or the location of a partition 
force a reboot. 



For more information about FDISK see OS/2 V2.0 Operating System Installation 
Guide. 
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Appendix E. FDISK Command Reference 



E.1 FDISK Command Line Interface 

In order to modify logical drives, change Boot Manager options via batch files or 
via remotely controlled interfaces like RCF for unattended environments, a 
command line interface is needed to provide the functions performed by FDISK 
in the PM and the full screen install environment. 

The FDISK command is documented in the Online OS/2 Command Reference on 
the OS/2 V2.0 system. 

The basic FDISK command line reads as follows: 

FDISK /parameter: value /optionsvalue 
Each FDISK statement consists of a: 

• Parameter, with or without a value and 

• Options with or without values. 

These are described in the following section. 

E.1.1 The Parameter of the FDISK Command Line 

The FDISK Parameter initiates the actual execution of the command. The 
following parametenvalue s are available: 

• /query 

Returns a list of all partitions and unused areas on the disk(s). 

• /create:name 

Creates a partition with the optional boot name assigned. 

• /delete 

Deletes a partition. To delete all partitions on a physical disk use 
/de1ete:all /disk:n 
where n is the disk number. 

• /setname:newname 

Sets the boot name of partition and makes it bootable from the Boot 
Manager menu. If the new name is left blank, the boot name is removed and 
will not be bootable from the Boot Manager menu. 

• /setaccess 

Sets accessibility of partition (creates the drive letter). Use this setting to 
select a primary partition as the C: drive if you have multiple primary 
partitions. 

• /startable 

Sets a partition startable, thereby making it the default partition to start from 
automatically. The OS/2 V2.0 installation process will automatically set the 
Boot Manager partition Startable, if one is present. 

• /file:filename 

Processes all FDISK commands in the file filename. The Options must be 
separated from the Parameter and each other by commas. See Appendix F. 



© Copyright IBM Corp. 1992 



155 





“Automating Fixed Disk Partitioning" on page 159 for an example of the use 
of this command. 



E.1.2 The Options of the FDISK Command Line 

In the contrary to the Parameter, the Options are arguments that limit the actions 
of the Parameters. For example: the command “query” without any Options 
would output all partitions on all drives in the system. If the Option “/drive:2 
/vtype:1" is added, then only the primary partitions on drive 2 would be output. 

The following Options and associated values are available: 

• /name:cccccccc 

Specifies a partition boot name. The value cccccccc may be any 
alphanumeric, special character, or blank and is case sensitive and must be 
enclosed in quotes if imbedded blanks are used. 

Example: 

/name: H Sys 0S2". 

When doing a query operation, a pseudo name is assigned to every partition 
and free space that doesn't have a boot name assigned. 

Note: This name is not set as the partition name, but only used as a 
temporary identifier for the user. Since the user doesn't have a visual 
representation as with the full screen FDISK, these pseudo names can be 
used in place of real names for the name Option. 

• /disk:n 

Specifies the disk number. The value of n can be any number between 1 and 
the number of disks in the workstation. 

• /fstype:hxx (or) itttttt 

• File system type 

hxx = where xx is the system indicator as defined in the partition table or 
tttttt can be: 

— dos 

— fat 

— hpfs 

— free 

— other 

• /start:c 

Create partition starting at location c, where c can be: 

— t = top of partition 

— b = bottom of partition. 

• /size:mmmmmm 

The size of the partition where mmmmmm is the amount of space in 
megabytes. 

• /vtype:X 

Specifies the partition type. The value of X can be: 

— 0 = unusable 

— 1 = primary 

— 2 = logical 

— 3 = free space for primary or logical. 

• /bootable:s 
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Specifies the "boot selectable" status where s can be: 

— 0 = specifies non-bootable partitions. 

— 1 = specifies bootable partitions. 

• /bootmgr 

Specifies the Boot Manager partition. 

E.1.3 Output Created by FDISK 

The command line FDISK will return a return code and the requested query 
information that can be piped and/or redirected. The return codes are: 

• 0 for a successful operation and 

• 1 for an unsuccessful operation. 

The output shown below is the result of the following statement: 

FDISK /query 



Drive Name Partition Vtype FStype Status 


Start 


Size 


1 00000020 




1 


0a 


0 


0 


i 


1 DOS 


C: 


1 


01 


1 


1 


5 


1 OS2V20 


D: 


2 


07 


1 


6 


40 


1 SEED20 


E: 


2 


01 


1 


46 


4 


1 DATA 


F: 


2 


01 


1 


50 


8 



Figure 63. Sample Output from FDISK Command Line Query 
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Appendix F. Automating Fixed Disk Partitioning 



This appendix describes recommendations for partitioning fixed disks prior to 
installing OS/2 V2.0. It also provides some sample programs to automate the 
process as part of installation. 



F.1 Fixed Disk Partitioning Recommendations 

The recommended fixed disk setup for OS/2 V2.0 is as follows: 



Table 9. Recommended Fixed Disk Partitions 


Partition 


Drive 


Size 

(MB) 


Notes 


BOOTMGR 


- 


1 


Optional 


OS2V20 


C: 


40 


OS/2 V2.0 


SEED20 


D: 


4 


Seed maintenance system 


DATA 


E: 


? 


Remainder of drive space 


Note: Create a DOS partition only if you have a requirement to boot the system 
under DOS. In this case DOS must be installed on the Primary partition, and the 
OS2V20 partition will be on drive D:. If DOS is used then the DATA partition should 
be formatted using the FAT system. Installation of the BOOTMGR and SEED20 
partitions is recommended for ease of future maintenance. 



F.1.1 The OS/2 V2.0 SETBOOT Command 

If Boot Manager is installed on the system the facilities of the OS/2 V2.0 
SETBOOT command also become available. SETBOOT is documented in the 
online OS/2 Command Reference. 

The following commands may be useful to enhance automation of client fixed 
disk partitioning: 

• This command sets the default partition to be booted as "OS2V20": 

SETBOOT /0:OS2V20 

• These commands set the partition to be booted on the next IPL as “SEED20”: 

SETBOOT /l: SEED20 
SETBOOT /X:l 

• This command reboots the workstation: 

SETBOOT /B 

• This command immediately reboots the workstation using the partition which 
is the E: drive: 

SETBOOT /IBD:E 

The SETBOOT /IBD command does not require Boot Manager installed to 
operate. 
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F.2 Using REXX Code to Create Partitions on Hard Disks 

The default installation using a response file creates one large partition. In order 
to achieve the flexibility required to automate the fixed disk partitioning the 
power of REXX is needed. 

It is assumed that the sample code in this appendix (DISKPREP.CMD) will be 
executed before the OS/2 V2.0 response file installation is started. This code 
assumes that the administrator wishes to repartition the client fixed disks as part 
of the installation process. 

All data on the client fixed disks will be lost. 

A backup procedure should be included as part of the installation procedures if 
there is data on the client disks which must be saved. This data could be 
restored in a UserExit of the response file installation. 

The code included here could be modified to keep some partitions on the disk 
and delete others, possibly removing the need for backup. For example, if the 
client was partitioned as: 



Table 10. Existing Fixed Disk Partitions - Example 


Partition 


Drive 


Size 

(MB) 


Notes 


OS2V13 


C: 


40 


Existing OS/2 VI .3 


DATA 


D: 


60 


User Data 


SCRATCH 


E: 


^20 


Scratch partition 



The drive could be repartitioned to: 



Table 11. New Fixed Disk Partitions - Example 


Partition 


Drive 


Size 

(MB) 


Notes 


OS2V20 


C 




40 


OS/2 V2.0 (Renamed only) 


DATA 


D 




60 


User Data - untouched 


SEEDV20 


E: 




4 


New partition 


SCRATCH 


F: 




15 


New partition 


BOOTMGR 


- 


1 


BootMgr (end of Free Space) 



In this case only the data on the SCRATCH partition is lost, the other partitions 
are untouched by the procedure. 

F.2.1 Summary of DISKPREP.CMD Function 

The sample REXX code in this appendix will perform the following steps: 

• Check for the existence of a partition named “OS2V20.” If such a partition 
exists the rest of the program is skipped and the response file installation 
process will continue. 

• If no such partition exists, the code will delete all partitions on the disk and 
run the FDISK program to create the partitions required. 



160 OS/2 V2.0 Remote Installation 






































• The user will then be prompted with a panel to reinsert the "Installation” 
diskette and reboot. 

• The second time through the procedure, an “OS2V20" partition will exist so 
installation will continue. 

F.2.2 Accessing REXX From a Client Workstation 

In order to gain access to OS/2 V2.0 REXX from the minimal systems booted for 
installation, several requirements must be met: 

1. The OS/2 V2.0 REXX DLLs must be in a directory that is referenced in the 
LIBPATH. 

2. The OS/2 V2.0 REXX MSG files must be in a directory that is referenced in 
the DPATH. 

3. The program REXINIT.EXE must be run to initialize the REXX functions. 

For specific details on setting up the server and the client LT diskette to allow 
REXX access, see the chapter which describes the LAN redirection method you 
are using. For TCP/IP, see 6.3.3, "Preparation of the NFS Client LT Diskette” on 
page 40. For Novell, see 7.3.3, "Preparation of the Novell LT Diskettes" on 
page 72. 

The REXX programs DISKPREP.CMD and PIPE.CMD should be copied to the 
server, so they become accessible from the client's redirected drive. The 
programs are explained in detail below. 

The FDSK.DAT file that defines how the client drives will be partitioned must also 
be copied to the server. See F.2.4, “The FDISK 'FILE:' Parameter” on page 162 
for a description of FDSK.DAT. 

F.2.3 Calling a REXX Procedure 

Calling REXX procedures at the very beginning of the remote installation can be 
accomplished in different ways: 

1. Extending the PROTSHELL in the CONFIG.SYS file on the LT diskette. 

This CMD is called before the remote installation process starts. None of the 
response file variables can be accessed because at this early stage the 
response file has not yet been interpreted. 

The following PROTSHELL statement is a sample, calling a REXX procedure 
(DISKPREP.CMD) before the actual install: 



PROT$HELL=cmd.exe /K "Z:\DISKPREP.CMD & rspinst.exe a:\os2se20.rsp" 



2. Adding a call to the installation batch file. 

If the installation procedure used starts a batch file that calls RSPINST.EXE, 
add the call to DISKPREP.CMD into the batch file after drive redirections are 
made, but before RSPINST is called. 
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F.2.4 The FDISK 'FILE:' Parameter 

E.1, "FDISK Command Line Interface” on page 155 describes all valid FDISK 
command line parameters. DISKPREP.CMD is written so that all disk partitioning 
is done with one command: 

FDISK /file: FDSK.DAT 

This allows the administrator to define how the fixed disk will be partitioned 
independent of the DISKPREP.CMD program. Here is an example FDSK.DAT, 
which will create a drive setup identical to that described in Table 9 on 
page 159, assuming Boot Manager has already been installed: 



/create :OS2V20, /si ze: 40,/vtype: 1 
/c reate : SEED20 , /s i ze : 4 , /vtype : 2 
/create: DATA, /vtype:2 



Figure 64. Example FDSK.DAT File 



F.3 The Sample REXX Partitioning Programs 

Two programs are included: 

• PIPE.CMD 

PIPE.CMD is a utility that takes the output from a command and places it 
onto the REXX queue. 

• DISKPREP.CMD 

DISKPREP.CMD performs the actual disk partitioning. 

DISKPREP.CMD requires the SOURCEPATH environment variable. It expects to 
find PIPE.CMD and FDSK.DAT in the directory pointed to by SOURCEPATH. 



F.3.1 PIPE.CMD 

The PIPE.CMD should be placed in the root of the directory specified in 
SOURCEPATH. PIPE.CMD is included on the Sample Code Disk. 



/* Take lines piped in and queue them */ 
do while lines() 
line=linein() 
queue line 
end 



Figure 65. PIPE.CMD Program 



F.3.2 DISKPREP.CMD 

A listing of DISKPREP.CMD follows. This program is included on the Sample 
Code Disk. DISKPREP.CMD requires that the SOURCEPATH environment variable 
has been set, and that PIPE.CMD and FDSK.DAT have been placed in the root of 
SOURCEPATH. 
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say 1 *; 

say center( 'Copyright IBM Corporation 1992. All Rights Reserved. ' , 78) ; 
say ' ’i 

say center('This program will destroy everything on the fixed disk', 78); 
say center ('Do you want to continue ? fflY/N" *,78) ; 
do forever 
pull answer 

if answer*' Y' then leave 

if answer B 'N' then exit 8 /* Set errorlevel 8 */ 
else 

call logo; 
end 

/* Execute the disk partitioning */ 

/* Assume 1 physical disk */ 

spath'\disk_l\fdisk /del ete : a 1 1 /disk:l 'rdir 
/* Add BootMgr */ 

spath'\disk_l\fdisk /create /bootmgr 'rdir 
/* Execute batch commands in FDSK.DAT */ 
spath'\disk_l\fdisk /file: 'spath '\fdsk.dat 'rdir 

/a**************************************************************** j 
/* Subroutine to write banner to screen */ 

/ft****************************************************************/ 

say '<-[0; 7m 1 ; 

do* /* Normal information message */ 

'Gels'; /* Clear the screen */ 

say '«-[8;lH'j /* Move cursor to line 8 */ 



say 

say 

say 

say 

say 

say 

say 

say 

say 

say 

say 

say 

say 



V 

V 



1eft('=',76,'=') || Y; /* Put 

1 eft ( * ',76) || 'J*; /* message 

center('The fixed disk preparation is complete 
left(* *,76) || 'I'; 

center ('The System must now be rebooted. 
leftC ',76) || 'I'; 

center ( 'Remove the diskette from the drive 
center ('and insert the OS/2 V2 Installation diskette. ' i 76) jj 
left ( * ' ,76) || 'J'; 

center( 'Press and hold the Ctrl and Alt keys, 1 ,76) || 

center('and press the Del key to reboot the system. ' ,76) jj 

left(' ',76) | | '| '; /* in a */ 

1 eft ( '= * , 76, '=’) || ' ; /* pretty box */ 



',76) | | 'I 
‘,76) || 
’*76) || 



end; 

do forever 
nop; 
end 
end 

/* otherwise continue 



Figure 66 (Part 2 of 2). DISKPREP.CMD Program 
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Appendix G. Printer Response File Keyword Definition and Sample 



G.1 Multiple Printer Remote Installation Program 

The following chapter describes the use of the multiple printer remote 
installation program. The first part will give a brief description of the program, 
the second part will describe in detail the command line parameters and the 
third part will give a detailed description of all keywords available. The chapter 
will conclude with an example utilizing the UserExit keyword of the response file. 

Note 

Due to last minute changes from development in the design of the OS/2 V2.0 
remote installation process, this program cannot be run as a UserExit. To use 
this program, boot again with an Installation diskette at the completion of the 
OS/2 V2.0 install process. Insert another LT diskette which starts a command 
prompt, and run the PRINTERS.CMD from this prompt. You must run this 
program before the OS/2 V2.0 system has booted from the fixed disk. You 
may also run the program at any time if PM is active, on an installed OS/2 
V2.0 system, and the printer objects will be created on the Desktop. 

Example OS2_SHELL in CONFIG.SYS of LT diskette to run command prompt: 

SET 0S2_SHELL-cntd.exe 



G.1.1 Introduction 

The multiple printer remote installation program (RINSTPRN) for OS/2 2.0 was 
written during a residency at the Boca ITSC. Its purpose is to make it possible to 
install multiple printers and queues via a response file instead of going through 
many complicated panels. It performs the basic installation of printers, queues 
and ports and configures communication ports. It also lets the user define the 
default printer and default queue. Additional -unconnected- printers can also be 
defined. 

Final adjustments of printer driver specific parameters (printer properties, job 
properties, additional fonts, option.s etc.) still need to be performed if default 
settings are not sufficient. 

The program reads the response file, interprets it and looks for consistency 
between the defined queues, printers and other values. After finishing this step 
it installs the printers, drivers and queues. All actions are logged into a log file 
for administrative purposes. 

The drivers that need to be installed can be read from either drive A: or B:. The 
program then prompts for diskette insertion on that specific drive. For any other 
drive letter the program looks on that specific drive for root subdirectories with 
the names \PMDD_1 to \PMDD_n, which should be images of the original printer 
driver diskettes. 

This program makes it possible to administer complex printer and queue 
configurations, without the administrator being at the location for installation. 
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Note: Already installed printer drivers will automatically be replaced by the 
program. 

The sample at the end of this appendix describes a rather complex configuration 
of queues and printers and provides an overview showing the strengths of this 
program. 

G.1.2 Command Line Parameters 

The program to be called has the name RINSTPRN.The following keywords can 
be used on the command line: 

DESC 

DRIVER 

LOG 

RESPONSE 

SOURCE 

TARGET 

Each keyword is optional. Keywords can be used in any order. If the same 
keyword appears twice on the command line, the keyvalue of the last occurence 
is used. The keywords are followed immediately by an " = " (equal) sign and a 
keyvalue. Blanks are not allowed between keyword, equal sign and keyvalue. 
Keywords are separated by one or more blanks. Misspelled keywords are 
logged into the log file and simply ignored. The processing will continue. 

• DESC = 

This keyword defines the location of the printer description list. A partially or 
fully qualified OS/2 pathname, including a drive letter, can be used. 

Note: If the drive letters "A:" or "B:" are used, make sure the driver diskette 

# 1 is in the specified drive before starting the program. 

The PRDESC.LST changes with every release. A proper printer install can 
only take place if the PRDESC.LST matches the driver install diskettes. The 
current version of PRDESC.LST resides on diskette # 1 of the driver 
diskettes. 

Default: PRDESC.LST in the working directory. 

For example: 

RINSTPRN DESC=Z : \ PMDD_1\ PRDESC . LST 

• DRIVER = 

This keyword defines the location of the printer driver list. A partially or fully 
qualified OS/2 pathname, including a drive letter, can be used. 

Note: If the drive letters "A:" or "B:" are used, make sure the driver diskette 

# 1 is in the specified drive before starting the program. 

The PRDRV.LST changes with every release. A proper printer install can only 
take place if the PRDRV.LST matches the Driver install diskettes. The current 
version of PRDRV.LST resides on diskette # 1 of the driver diskettes. 

Default: PRDRV.LST in the working directory. 

For example: 

RINSTPRN DRI VER=Z : \ PHDD_1\PRDRV . LST 

• LOG = 

This keyword defines the location of the log file into which the RINSTPRN 
program logs its response file analysis, activities and execution results. A 
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partially or fully qualified OS/2 pathname, including a drive lette.r can be 
used. 

Default: RINSTPRN.LOG in the working directory. 

For example: 

RINSTPRN L0G=C i\RINSTPRN.LOG 

• RESPONSE = 

This keyword defines the location of the printer install response file. A 
partially or fully qualified valid OS/2 pathname, including a drive letter, can 
be used. 

Note: If the drive letters "A:" or "B:" are used, make sure the proper 
diskette is in the specified drive before starting the program. Please be 
aware of the fact, that when the keywords DESC and DRIVER point to the 
same drive, all three files have to be on this same diskette. 

Default: PRINTER.RSP in the working directory. 

For example: 

RINSTPRN RESPONSE-Z : \PRINTER . RSP 

• SOURCE = 

This keyword defines the source drive where the drivers and fonts to be 
installed are located. Only one drive letter without a colon must be specified. 
If the drive letter is A or B, the program asks for the printer driver diskettes 
on A:. In any other case (C to Z) the program looks for root subdirectories 
called PMDD_1 to PMDD_n (depending on how many disks are mentioned in 
column two of the PRDRV.LST) on the specified drive. This drive can also be 
a redirected drive. 

Default: A. 

For example: 

RINSTPRN SOURCES 

• TARGET = 

This keyword defines the target drive where the OS/2 V2.0 system has been 
installed. Only one drive letter without a colon must be specified. Use this 
keyword if OS/2 V2.0 has been installed to a logical partition, rather than a 
primary partition. The default value of this keyword is C. 

Default: C. 

For example: 

RINSTPRN TARGETED 

The following complete example looks for a printer response file on redirected 
drive " Z :" with the name PRINTER.RSP. The PRDRV.LST is located on redirected 
drive "Z:" in the root subdirectory \PMDD_1. The PRDESC.LST is located on 
redirected drive "Z\" in the root subdirectory \PMDD_1. The USERnnnn.LOG file 
will be written to the redirected drive "Z:" thereby gathering the install 
information on the server. 



RINSTPRN RESPDNSE=Z:\PRINTER.RSP DRIVER=Z:\PMDD 1\PRDRV.LST 

DESC-Z: \PNDD_1\PRDESC. LST L0G°Z: \USERnnnn.LOG SOURCES TARGETED 
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G.1.3 Printer Response File Keywords 

The following keywords are available for the remote installation of printers. With 
these keywords up to 12 printers and 20 queues can be defined for one 
workstation. Most of the keywords are suffixed. The keywords are described in 
alphabetical order. Each of the following keywords is explained in detail on the 
following pages. 

Additional Printer 

Comm Port 

DefaultPrinter 

DefaultQueue 

Printer 

PrinterDesc 

PrinterName 

PrinterPort 

Queue 
QueueDesc 
QueueName 
Queue Proc 

Each keyword is optional. Keywords can be used in any order. Only one 
keyword is allowed per line. Keywords are followed immediately by an " = " 
(equal) sign and a keyvalue. Blanks are not allowed between keyword, equal 
sign and keyvalue. There exists no concatenation of lines. Comment lines start 
with an (asterisk). Suffixable keywords must have a valid suffix. 

Note: 

The CommPort keyword must be suffixed with a value between 1 and 3. The 
CommPort suffix corresponds with the COM address. So CommPortl 
corresponds to COM1. 

The Printer keywords (Printer, PrinterPort, PrinterName and PrinterDesc) must 
be suffixed with a value between 1 and 12. So Printer5 corresponds to 
PrinterPortS and PrinterNameS, etc.. 

The Queue keywords (Queue, QueueName, QueueDesc, QueueProc) must be 
suffixed with a value between 1 and 20. So Queue12 corresponds to 
QueueDesc12, etc.. 

G.1.4 KEYWORD Description 

• AdditionalPrinter 

Specifies which printers should be installed in addition to the ones defined 
on the Printer keyword(s) within this same response file. The keyword is 
followed by an equal sign and the keyvalue for the entry in the printer 
description file (PRDESC.LST). The keyvalue is the line number of the 
specific line in PRDESC.LST. 

More than one keyvalue can be defined on the AdditionalPrinter statement. 

The natural limit on the number of keyvalues is the line length of 200 
characters. If more than one keyvalue has been defined, values must be 
separated by either one or more blanks and/or a comma. 

Note: A description of the PRDESC.LST is shown on page 130 of 

Appendix A, “Response File Keyword Reference, Samples And 
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Details,” section A.5, “Printer Description Table for Printer 
KEYWORD.” 

Keyword = printerdriver printerdriver .... 

For example: AdditionalPrinter=24 27 

• CommPort 

Specifies the setting of the communication ports. The parameters are 
positional and separated by a comma. If a parameter is omitted the 
positional comma still must be placed (see example): 

Keyword = b,p,d,s,h 

b = Baudrate 

p = Parity, 0 = Odd, E = Even, N = None 
d = Databits, valid values are 5 to 8 
s = Stopbits, valid values are 1, 1.5 and 2 
h = Handshake, H = Hardware, N = None 

Valid baudrates are: 110, 150, 300, 600, 1200, 1800, 

2400, 3600, 4800, 7200, 9600, 19200 

Defaults: 1200,0,7, 1,N 

For example: CommPort 1=9600, N, 8, 1,H 

CommPort2=9600, , , , results in (9600,0,7, 1,N) 

CommPort3=4800,,8,,H results in (4800,0,8, 1,H) 

• DefaultPrinter 

Specifies the suffix number from the printer keyword of the printer that 
should be the default printer. 

Keyword = any valid printer suffix number 

For example: DefaultPrinter=l 

• DefaultQueue 

Specifies the suffix number of the queue keyword of the queue that should be 
the default queue. 

Keyword = any valid queue suffix number 

For example: DefaultQueue=l 

• Printer 

With the keywords Printerl to Printer12 up to 12 printers can be defined. The 
keyword is followed by an equal sign and the keyvalue for the entry in the 
printer description file (PRDESC.LST). The keyvalue is the line number of the 
specific line in PRDESC.LST. 

More than one keyvalue can be defined per printer statement. This makes it 
possible to define different drivers per printer. 

The natural limit on the number of keyvalues per printer is a line length of 
200 characters. If more than one keyvalue has been defined, values must be 
separated by either one or more blanks and/or a comma. 

Note: A description of the PRDESC.LST is shown on page 130 of 

Appendix A, “Response File Keyword Reference, Samples And 
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Details,” section A.5, “Printer Description Table for Printer 
KEYWORD." 



Keyword = printerdriver printerdriver .... 

For example: Printerl=24 27 
Pri nter2=87 

• PrinterDesc 

Specifies the description for a printer. 

In case this statement has been omitted for a specified printer the program 
takes the description found in PRDESC.LST and adds the PrinterPort to it, for 
example "IBM 4202 Proprinter III XL at LPT2": 

Keyword = any 60 character ASCII string 

For example: PrinterDescl=My favorite printer IBM 4019 

• PrinterName 

Specifies the name of the printer. If the name is longer than eight characters 
it will be truncated. 

In case this statement has been omitted for a specified printer the program 
takes the name of the first driver used by this printer and adds the number of 
its PrinterPort for example "IBMNULL1","PSCRIPT2": 

Keyword = any 8 character ASCII string 
For example: PrinterNamel=MY4019 

Note: If two printers use the same driver, one on LPT1 and the other one on 
COM1, this yields a duplicate name. As a result the second printer will not 
install. 

• PrinterPort 

Specifies the port the printer is connected to. 

Keyword = printerport 

printerport = LPT1 - LPT 12, C0M1 - COM3 

For example: PrinterPortl=LPTl 

PrinterPort2=C0Ml 

• Queue 

Describes the connection of a queue to one or more printers. The first 
parameter is the number of the printer, the second optional parameter 
defines the driver index within the printer definition which should be used by 
this queue. This keyword may occur more than once for a queue. 

Keyword = printernumber driverindex 

printernumber = the suffixed number of the appropriate 
pri nter 

driverindex = index in the driverlist of the Printer 
statement 

For example: Queuel s l,2 

Queuel=2 
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This example connects Printer1/Driver2 and Printer2 to Queue! 

• QueueDesc 

Specifies the description for a queue. In case this statement has been 
omitted for a specified queue the program takes the description found in 
PRDESC.LST and adds the PrinterPort to it for example, "IBM 4202 Proprinter 
III XL at LPT2". If no printer is connected to the queue, the description will 
be blank. 

Keyword = any 60 character ASCII string 

For example: Queuel=Queue for my favorite printer IBM 4019 

• QueueName 

Specifies the name of the queue. 

In case this statement has been omitted for a specified queue the program 
takes the name of the driver used by this queue and adds the number of its 
PrinterPort. for example, "IBMNULL1","PSCRIPT2". 

Note: If a queue is not connected to a printer or its name has already been 
generated for another queue the queue will not install. 

Keyword = any 8 character ASCII string 

For example: QueueNamel=MY4019Q 

• QueueProc 

Specifies the queue processor used by this queue. If this keyword is not 
defined for a queue, either PMPRINT or PLPLOT will be used as queue 
processor, depending on the printer driver used. 

Keyword = any valid queue procedure name 
For example: QueueProcl=PMPRINT 



G.1.5 Sample Printer Response File 

The following scenario does not reflect a regular installation, but shows some 
capabilities of OS/2 V2.0. 

Three printers are connected to a workstation: 

• IBM 4202 Proprinter XL 

• IBM Pageprinter II 

• Apple LaserWriter Plus. 

These printers are connected to different printer ports: 

• The IBM 4202 Proprinter is connected to LPT1 

• The IBM Pageprinter II is connected to LPT2 

• and the Apple LaserWriter Plus is connected to COM! 

The COM1 has been defined as follows: 

Baudrate 9600 
Parity None 

Databits 7 

Stopbits 1 

Handshake Hardware 

Five queues are installed: 



Appendix G. Printer Response File Keyword Definition and Sample 171 




• IBMNULL1: uses the IBM4202 Proprinter with the IBMNULL driver on LPT1. 

• IBM42XX1: uses the IBM4202 Proprinter with the IBM42XX driver on LPT1. 

• PSCRIPT2: uses the IBM Pageprinter with the PSCRIPT driver on LPT2 

• PAGEP Q: uses the IBM4202 Proprinter with the IBM42XX driver on LPT1 or 

the IBM Pageprinter with the PSCRIPT driver on LPT2. 

• LASERP_Q: uses the Apple** LaserWriter Plus with the PSCRIPT driver on 
COM! 

The default queue and printer are PSCRIPT2. 

View the following figure for a graphical understanding of the above-described 
scenario. 



Queue Procs Queues Printers 

Object Object Object 



Drivers Printer Ports 

Object Object 




(ZD Default Queue 
(ZD Default Printer 



' \ J* 



Printer - Driver Connection 
Queue • Printer - Driver Definition 



Printerl : IBM 4202 Proprinter XL on LPTl 
Prfnter2: IBM Personal Page Printer il on LPT2 
Printerd: Apple LaserWriter Plus 



Figure 67. Sample Workstation Printer Scenario 



The following figure shows the printer response file used to describe this 
installation. 
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Prlnterl = 187 139 

* 197 = IBH 4282 Proprinter XL (IBH42XX.DRV) 

* 129 = IBH NULL Printer Driver 
Pr1nter2 = 131 

* 131 = IBH Personal Page Printer 11-31 (PSCRIPT.DRV) 
Printer3 » 7 

* 7« Apple LaserWriter Plus v42 2 (PSCRIPT.DRV) 

* “ 

Printer Portl = LPT1 
PrinterPort2 = LPT2 

Print erPort3 = C0H1 
* 

PrinterDesc3=Apple LaserWriter Plus 
* 

Queuel = 1,2 

* Queuel connected to Prlnterl and uses IBHNULL 
Queue2 « 1,1 

* Queue2 connected to Prlnterl and uses IBH42XX 
Queue3 = 2 

* Queue3 connected to Printer2 and uses PSCRIPT 
Queue4 = 1,2 

* Queued connected to Printerl and uses IBHNULL 
Queue4 = 2 

* Queue4 also connected to Pr1nter2 
Queues = 3 

* Queues connected to Printer3 and uses PSCRIPT 

* 

QueueName4 = PAGEP Q 

QueueNameS = LASERP_Q 
* ” 

QueueDesc4 = Queue connected to two printers 

QueueDescS ° Queue that prints on laser printer 
* 

Default Printer = 2 
* 

Default Queue = 3 
* 

Additional Printer = 31 99 

* 31 = Epson LQ-18S8 (N9) 24 pins - 136 columns: (EPSON. DRV) 

* 99 = IBH 4829 Laserprinter 18L (LASERJET. DRV) 

* 

CommPor t 1*9600 ,N,8,1,H 



Figure 68. Sample Printer Response File 



G.1.6 Printer Installation Sample 

This program can be used in two ways. It can be started in an OS/2 Window or 
full-screen session, using Drive A: or B: or any other local or LAN drive. If a 
drive letter other then A: or B: is used, the program looks for root subdirectories 
\PMDD_1 to \PMDD_n on that drive. 

It also can be used during the regular remote install procedure. In this case it 
only needs one entry in the response file to trigger the execution of the program. 
A sample of this would be: 
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User Exi t **pr i nters . cmd 



This sample line calls a CMD procedure called PRINTERS.CMD. This can located 
anywhere along the PATH statement as set in the CONFIG.SYS. The contents of 
PRINTERS.CMD could be: 



REH PRINTERS.CMD 

REM set the correct working directory, 

C: 

CD \0S2\DLL 

REM call the program 

RINSTPRN RESPONSE**! \PRINTER.RSP DRIVER**: \PMDD 1\PRDRV.LST 
DESOZ : \PMDD_1\PRDESC . LST L0G=X:\RINSTPRN7L0G S0URCE=Z 



Figure 69. PRINTERS.CMD to be Called from UserExit 

Note: For RINSTPRN to run properly, it needs access to the C:\OS2\DLL 
subdirectory, which was installed by the RSPINST program before it executed the 
UserExit keyword. RINSTPRN needs PM to be available while executing. The 
LIBPATH statement therefore must be set up exactly as shown below in the 
CONFIG.SYS sample. 

If we assume that Z:drive is the redirected drive, on which the PRDRV.LST and 
PRDESC.LST reside on the PMDD_1 root subdirectories, the program would read 
these two files from the specified drive. 

The PRINTER.RSP response file for remote printer install is also assumed to 
reside on a redirected drive. In this sample it resides on the redirected X:-drive 
which is a redirected drive which holds the private PRINTER.RSP file and stores 
the log file. 

Independent of the method by which a LAN redirected drive was created {TCP/IP 
or Novell Netware), to be able to store printer response files individually, the 
private drive letter or subdirectory needs to be part of the PATH statement on 
the CONFIG.SYS. In this sample the assumption was made, that the redirected 
X:drive looks at a private subdirectory on the server in which a private version of 
PRINTERS.CMD was called. Utilizing this method, each workstation could use its 
own customized PRINTER.RSP file. 

The results are stored on the same redirected X:drive. 

The LIBPATH statement must have the as first entry to have OS/2 V2.0 look 
at the working directory for DLLs. The PATH and DPATH statements must at 
least have Z:drive for access to the PMDD-diskette images on the server. The 
following CONFIG.SYS file sample shows the minimum requirements for the 
above sample to run: 
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SET 0S2_SHELL-RSPINST.EXE A:\OS2SE20.RSP 



LIBPATH*. ;\} 



m 

SET PATH=\ i\0S2; \0S2\S YSTEM ;\0S2\I NSTALL; X: \ ;Z s \ ; A : \ ; 

SET DPATH=\;\OS2;\OS2\SY$TEM;\OS2\INSTALLjX:\}Z:\;A:\; 

■ 
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Appendix H. Source Code for Remote Printer Installation Program 



H.1 Make File for RINSTPRN C Routines 

Compiler control file used when compiling and link editing the RINSTPRN.EXE, 
the source for which is listed later. 

rinstpm.exe: rinstpm.obj log.obj response. obj respchk.cbj rinstdrv.abj rinstcisc.obj rinstpm.def 

lime rinstpnHlog*response*respchx+rinstdrv+Hnstnsc /A:l6,r1nstpm,rinstprn,ll ibce+os? /KOd /MAP, rinstpm.def; 

rinstpm.obj: rinstpm.c rinstpm.h 

Cl /c /Od /Zi /2p /Al /W3 /C2s /Gc rinstpm.c 

log.obj: log.c 

cl /c /Od /Zi /Zp /At /W3 /62s /Gc log.c 

response. obj: response. c rinstpm.h r_error,h 

cl /c /Od /Zi /Zp /At /W3 /G2s /Gc response. c 

respchx.obj: respchx.c rinstpm.h r_errar.h 

cl /c /Od /Zi /Zp /At /W3 /G2s /Cc respchK.c 

Hnstdrv.qbj: rinstdrw.c rinstpm.h 

cl /c /Od /Zi /Zp /AL /H3 /G2s /Gc Hnstdrv.e 

rinsttesc.obj: rinstnsc.c rinstpm.h 

cl /c /Od /Zi /Zp /al /W3 /G2s /Gc rinstnsc.c 



H.2 RINSTPRN.H C Header 



/* Header file for Renote Printer Installation Prcgran V 

# define KAXJ>R1NTERS 12 
•define KAX_QUEUES 28 
•define KAX’lPT 9 
•define MAx'cOM 3 



♦define OEFAUlT_lOGFUEKAf€ •RINSTPRN.LCG" 

•define UEY_PRIHTER0ESC 8 

•define KEY_Pfll NT £ RkAh£ 1 

•define KEY~PRINTERP0R7 2 

•define «Yj>RlNT£R 3 

•define KEYJ1UEUE0ESC 4 

•defi ne KEY~OUEUEMAME 5 

•define KEY..QUEUEPROC 6 

•define KEYJUEUE 7 

•define KEy’coWPORT B 

•define KEy'oEFAULTPRINTER 9 

♦define KEy”0EFAUITQUEUE 18 

♦define reyjlcditiokalprt 11 

•define GENERATED 8 

•define N0T_DEFINE0 -1 

•define IGNORED -2 

•define INSTALLJRRQR -3 

♦define OESCRIPTICN.LENGTH M 

•define PCRT20S(p) (-(PUSHORTHp)) 

/* Structure* defi nit ions */ 

typadef struct PRDRV /• Printer driver structure •/ 

( 

struct _PRDRV "next; /• next eletsent V 

PCKAR drvnane; /* filenone and extension of driver */ 

USKORT disxnuoj /• diskette nuefier driver resides on */ 

PCHAR keys /• key froa PM_OEVICE_ORIVER in 0S2.IHI */ 

PCKAR value; /• value froa PMJJEVICE.ORIVER in 0S2.INI */ 

BOOL instFlag; /• Installation flag */ 

} PRDRV, “PPRORV; 

typedef struct PROESC /* Printer description structure V 

{ 

struct _PROESC *next; /* next elenent «/ 

PCHAR drvnane; /* Driver naae */ 

PCHAR xey; /* key froa PMjPOOLEfiJD in 0S2.IMI V 

PCHAR desc; /* description of printer */ 

BOOL InstFlag; /* Installation flag •/ 

} PROESC, -PPROESC; 

/* Structure for printer driver definition */ 



© Copyright IBM Corp. 1992 
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typedef struct PRTORVDEF 

< 

struct JRTORVOEF -next; 

USHORT " index; 

) PRTQRVDEF. "PPRTORVDEF; 

/* Structure for printer definition •/ 
typedef struct PR1NTER0EF 

{ 

PPRTORVDEF Oriverlnfo; /- Chain to printer drivers */ 

SHORT Orvlnfoline; /" Line where drivers ore defined V 

SHORT Portline; /* Line where port is defined V 

SHORT NoeeLine; /• line where printer noise is defined */ 

SHORT OescLine; /* Line where description is defined */ 

CHAR Port (2); /* Printer port, */ 

/• 1. Cherocter: l - LPT V 

/• C » COH •/ 

/* 2. Cherocter: nunber of port V 
CHAR Name (18); /* Kane of printer */ 

CHAR Dtscri pt i on [ 0ESCR3 PT 1 CN_lE NGT H] ; /• Description V 

} PRINTEROEF, *PPRINTERQEF; 

/* Structure for connection of printer Queues to printers V 



typedef 

{ 


struct 


_PRT_C0NN 






struct PRT CONN -next; 








USHORT 


Printer; 


/" Nunber of printer 


V 




USHORT 


Driver; 


/* printer driver number 


V 




SHORT 


Line; 


/• Nunber of line in response 


file V 


) 




PRT_C0NN, "PPRTJ 


CONN; 




/* Structure for 


queue definition **/ 






typedef 

{ 


struct 


JJUEUEDEF 






PPRT CONN PrtConn; 


f* Chain to printer connection 


, •/ 




SHORT 


OueutOri verlndex; 


5 /" Driver index for queue 


V 




SHORT 


Nanai ine; 


/* Line where queue name is defined */ 




SHORT 


QueueprocLine; 


/* Line where queue processor 


is defined 




SHORT 


OescLine; 


/* Line where description is defined V 




CHAR 


Nane(l9j; 


/* Nane of queue 


V 




CHAR 


0ueueproc[10]; 


/" Nane of queue processor 


*/ 




CHAR 


Oescripti on (0ESCRIPTI0N_ LENGTH); /• Description 


*/ 


) 




QUEUEDEF, *PQUEUEOEF; 




/* Structure for printer port definition */ 




typedef 

{ 


struct 








USHORT 


BaudRate; 








USHORT 


DataBits; 








SHORT 


Line; 


/* line in response file */ 






CHAR 


StopBits; 


/- A ■ 1 * 
/* B - l.S •/ 
/- C - 2 V 






CHAR 


Parity; 








CHAR 


KandShaxe; 






) 




P0RT_0EF, -PPORT 


.QEF; 





/* Structure for cocpiete response file info "/ 
typedef struct 
{ 

PPRINTERQEF PrinterDef; f* Definitions of printers V 

POUEUEOEF QueueDef; /* Definition of Queues */ 

PPORTJJEF PortOef; /• Definition of corcrunication ports */ 

USHORT OefoultPrinter; /* Nunber of defoul t printer */ 

USHORT OefoultOueue; /* Nunber of default queue V 

SHORT OtfPrtLine; /* Line # of default prt definition */ 

SHORT OefQueLine; /* Line # of default que definition •/ 

} RESPONSEJNFO, -PRESPQNSEJNFO; 

/• Structure for translationtabie driwernane - pri nternane/queuenoce */ 
typedef struct 
{ 

PCHAR OriverNane; 

PCHAR PrinterPrefix; 

) TRANSJiAMES, *PTRANS_NAM£S; 

/* Structure for information eassage V 
typedef struct INFO MSC 
{ 

Struct _INF0_MSC -next; 

Char Messaged); 

} INF0_MSG, *PINF0_MSG; 

/* Functions •/ 

PPRDRV GetDri verNones (PCHAR Filenene); 

void log(lnt, char *); 

VOID AddErrortUSHORT LineNusber. USHORT ErrorNunber, PCHAR Text); 

VOID InfoMsg(PCHAA Text); 

PPRDESC Get Pri nterOescriptions (PCHAR FlieNaae); 

PRESPONSEJNFO ReodResponseFile (PCHAR F i 1 iN&ae, PPRDESC PrinterOesc); 
BOOL lsStringNuceric (PCHAR String); 

PCHAR St rip (PCHAR String); 

VOID CrossChec* (PRESPONSEJNFO Resoonstlnfo, PPRDESC PHnterOesc); 

VOID GenerateNace (PCHAR None, SHORT Printerlndex. 

SHORT PortNunber, PPRDESC PrinterOesc); 

V0I0 InstallOri vers(PRESPONSE_lNFO Responselnfo, 

PPRDRV PrTnterOrivers, PPRDESC PrinterOesc, 
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PCKAR InstOrive); 

BOOL Install PH nttrQrlver (PPRORV PrtOrv» PCHAR InstOrive); 

VOID Install PHnters(PAE5P0NSEJNF0 Responielnfo. 

PPRORV PrlntarOHvtrs. PPROESC PHntcrOesc); 
VOIO Install Queues (PRESPONSEJNFO Rasponstlnfo, 

PPROESC Prl ntcrOesc) ; 

PPROESC GetOescByNtaier (PPROESC OescPtr, USKORT Index); 

PPRORV GctOri verflyNane (PPRORV OrWerPtr. PCKAR Km); 

V010 G ene rat eDe sc (PCKAR Oesc, SHORT PHnterlndtx, 

PCKAR Part, PPROESC PrinterOwc); 

VOIO SetOefaul ts (PRESPOKSE JKFO Responselnfa); 

VOID SetCottttPort(PPORT_OEF’PortOef); 

VOID Marxlnsta) 1 vdDrl vers (PPRORV PrinterOrl vtrs); 

VOID SttLagFilcnm (PCKAR Ft 1 anas*); 



H.3 R.ERROR.H C Header 

/* Header ft la for error aas sages while Interpreting the response file */ 

/•«****«***»•***•* »•*•*««*«**•*•• *«»******»«**»**«*****ft**********ft*«***»iiy 

♦define KAXJRR0R5 108 

♦define RSP.NO.ERROR -1 

♦define INVALIOJ.IKE 0 

♦define iKVAllOJtEYVORO 1 
♦define IKVALIdIpORT 2 

♦define PORTJNJJSE 3 

♦define DUP l lCAT EXPORT « 

♦define DUP11CATEJ>R1NTEA 5 
♦define NQN_NUKERIC 6 

♦define INVJCEYVALUE 7 

♦define QU PL I CATE JCEY VALUE 8 
♦define OUPLICATE^POESC 9 
♦define OUPlICATE.PRTNAtf 19 
♦define PRTKAKE.TRUKCATEO 11 
♦define PRTKAMEJN_USE 12 
♦define OUPUCATE JDESC 13 
♦define DUPLICATE.OUEUENAME 14 
♦define QUEUENAHE_TRUNCATED 15 
♦define OUEUENAMEJNJISE 16 
♦define OUPUCATE.QUEUEPROC 17 
♦define INVAIID.QUEUEPROC 18 
♦define imvalid^parh 19 

♦define KON.KL»€R!C.PRT 20 
♦define HONJIUMEAIcIdRV 25 
♦define INVAUO.PRt'valUE 22 
♦define INYAUO_E)AY_ VALUE 23 
♦define ALREAOYJOKHECTED 24 
♦define OUPLICATEJWOEF 25 
♦define NONNUM£RIC_BAUCRATE 26 
♦define INVAIIOJAUDRATE 27 
♦define IKVAII0.PAA1TY 20 
♦define KONNUMERICJJATABITS 29 
♦define IKVALIO_OATA8ITS 38 
♦define lNVAtI0_$T0P8ns 31 
♦define INVAUQ.KANDSKAKE 3? 

♦define PRINTER j)£f MISSING 33 
♦define QUEUE.OEFjtfSSlNG 33 
♦define GENERATJWKEJNJSE 34 
♦define PRINTERJiOT_DEFlNE0 35 
♦define NO.VAllO_MKN£CTION 38 
♦define CU£UE_NAHE_INJJSE 37 
♦define GENQUEUE^NA«jN USE 39 



♦define 0£FAULT_K0T_0EF 39 
♦define OEFAULTJRROR 49 

♦define INV_DEFAULT_PRIHTER 41 
♦define INVJJEFAULTJJUEUE 42 
♦define PAT* FOUNO_lii_INI 43 
♦define GE N PAT_f 0 UN D_ I N_ I N 1 44 
♦define PORT_FOUNDJNJNI 45 
♦define OUE_FOUKOJNJNI 48 
♦define 6EKQUE_F0UKD_1N_INI 47 

♦define ASP “printer response file* 



typed* f struct 

{ 

USKORT Line Nutter; 

USKORT ErrorNuaber; 

PCKAR Text; 

) EARCR_STRUCT, *P£RROR STRUCT; 
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H.4 RINSTPRN.DEF Define File 

.*«*•«*« AVIOSAMP C Sample Program Module Definition File (.DEF) ******** 

; The module definition file supplies extra information about the program 
; module to the LINKER. 



NAME RINSTPRN WJNOOWCOMPAT 

DESCRIPTION ’Install printer drivers. Queues end ports’ 

STUB ’0S2STUB.EXE' 

DATA MULTIPLE 

STACK5IZE 4096 
KEAPSIZE 4096 

PR0TM00E 

; IMPORTS 

i SHEPIINITINIFIiES *SHPIINST.SHEPI1NITINIPILES 

; PRFOUERYPROFILESTRING-SHPIINST.PRFQUERYPROFIIESTRIKC 

; PftFWR!T£PROFUE$TRING‘SHPlIN5T.PRFURITEPROFlLESTRlNG 



H.5 Printer Driver List File PRDRV.LST 

This printer driver list file is included on the first printer driver diskette of OS/2 
V2.0. 

IBMNUIL.DRV 1 IBM Null Printer Driver 

LASERJET. DRV 1 HP taserjet III Printer Driver 

PSCRIPT.ORV 1 PostScript Printer Driver 

IBM4019.0RV 2 IBM 4019 Printer Oriver 

IBM42XX.0RV 2 IBM 42XX Printer Driver 

IBM52012.DRV 3 IBM 5201-2 Printer Oriver 

SMGXPJET.DRV 3 Paint jet Printer Oriver 

EPSON. DRV 4 Epson Printer Driver 

PLOTTERS. DRV 4 Plotter Oriver 

PHPiOTPD.DRV 4 PMPlOT Queue Processor Oriver 

IBM52XX.ORV 6 IBM 52XX Printer Driver 



H.6 C Source for RINSTPRN.C 

This module is the main routine for remote printer installation, that reads the 
printer list file as shown in H.5, “Printer Driver List File PRDRV.LST” and the 
printer description file shown on page 130 under Appendix A, “Response File 
Keyword Reference, Samples And Details,” section A.5, “Printer Description 
Table for Printer KEYWORD.” This module also invokes the read routine for the 
printer response file and installs printers and queues. 



/ 

/* Remote Printer Installation */ 

* * ••*••••/ 

♦Include <std1ib.h> 

♦include <stdio.h> 

♦include <meoory.h> 

♦include <string.h> 

♦include <coni o.h> 



♦define iNCLJflNSHELLOATA 
♦define INCL_D0S 
♦define INCL^SPL 
♦define INCLJ6 
♦include <os2.h> 

♦include "rinstprn.h” 

♦define DEBUG_no 
♦define 0EBUG~CHAIN_no 



static CHAR Buffer [1609]; 

CHAR TargetDir[255]; 

/* Function MAIN */ 

/* */ 

/* Parameter: */ 

/* */ 

/* The parameters defined for this progran ore keyword parameters. */ 
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/* At invocation time the position of parameters can vary. */ 
r V 
/" RESPONSE *nl nl » Name of response file, */ 
/* default ■ PRINTER. RSP V 
/* DRIVER-n2 n2 ■ Name of printer driver list file, */ 
/* default • PRDRV.LST »/ 
/* DESC-n3 n3 • None of printer description list file, */ 
/* default » PROESC.LST */ 
/* L06*n4 r>4 • Rase of Log File, */ 
/* default « RINSTPRN.LOG */ 
/* DRIVE »n5 n5 • Driveletter where the printer drivers V 
/* ere located, */ 
/• default » A */ 
/* 0RIVEl«n5 V 
/" v 
/* V 
/* Author: Gert Ehing Oecewber 1991 HSC 8oca Raton, Florida */ 

void cdecl main (argc, argv) 



int argc; 

char *argv[); 

{ 

static PPRORV PrinterOri vers; /* Pointer to chained list of V 

/• printer drivers */ 

static PPROESC Printerflesc; /* Pointer to chained list of V 

/• printer models */ 

static CHAR Oefaul tResponseFi 1 e[] « -PRINTER. RSP**; 

static CHAR Oefaul tOri verLlstF!le[] » -PRDRV.LST-; 

static CHAR OefaultPrinterDescriptionFileC] ■ -PROESC.LST"; 

PCHAR ResponseFileName ■ Oefaul tResponseFi 1e; 

PCHAR Dri verListFileNane ■ Oefaul tOri verii stFi le; 

PCHAR PrinterOescriptionFileNane » Oefaul tPri nterOescri pti onFi le; 

PR£SP0NSE_IhF0 RespOnselnfo; 

SHORT “ i; 

static CHAR Kwdl[] • ‘RESPONSE**; 

static CHAR Kwd?[j • "DRIVER-*; 

static CHAR Kwd3[j - *0ESC«"; 

Static CHAR Rwd4[j - "LOG-*; 

static CHAR Kwd5[] • -SOURCE-"; 

static CHAR Kwdsj] ■ -TARGET--; 

static CHAR Instal lationDri ve[] ■ -A-; 

static CHAR TargetDrive[] • "C"; 

if (argc > 1} 

{ 

if (! strccp (argvtl], -?")) 

{ 

printf( 

* RecotePrinterlnstal laticn\n* 

’ \n" 

■\n* 

" Syntax:\n" 

*\n“ 

/* 

- R1NSTPRN [RESPONSE-responsefile] [ORIVER-dri verl ist] [OESC-printerdesd istl\n" 
V 

h f An" 

t l\n^ 

* RINSTPRN r*“[RESPQNSE-responsefile]-*H H\n" 

* |-*— [DRI VER-dri verl i st] — 

" h^-[OESC»printerdesclist]-^H\n" 

" [LOG-logfilenace] — *^-|\n* 

h— [ SOURCE -drive} » i\n" 

- TARGET -drivel] *— J \n- 

-\n*); 

pri nt f £ 

responsefile Name of response file, default: PRlNTER.RSP\n" 

'* dri verl ist Name of printer driver list, default: PRQRV.lST\n" 

" printerdesclist Name of printer descr. list, default: PROESC.lST\n- 

- logfilenane Name of log file, default: RINSTPRN\n r 

*’ drive drive for installation, default: A\n“ 

- drivel Target drive for installation, default: C\n" 

-\n* 

-\n* 

* IT SC Ooca Raton, Florida\n“); 

exit(O); 

) 

/* Checm parameters *1 

Buffer[0]»‘\0' ; 

for (i * 1; i < argc; 1++) 

( 

if (str1en(argv[i]J >• sizeof(Kwdl)) 

{ 

if (! eeoi cop (argv (i], Kwdl, sizeof(Kwdl) - 1)} 

{ 

strupr(ResoonscFi 1 cNaoe « 4argv[i Hsizeof(Kwdl) *1]); 
continue; 

) 

> 

if (strlen(argv[i]) >• slzeof(Kwd2)) 

{ 

if (!memicEg}(orgv[f }, Kwd2, sizeof(Kwd2) - 1)) 

( 

strupr(Drl verl i stFi leName • iorgv[i][$izeof(Kwd2) -1]); 
continue; 

) 

) 
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if (strlen(argv[1J) >• slieof(Kwd3)) 

{ 

If (Iaeaic*>(argv[i], Kwd3, si i«of (Kwd3) - 1)) 

{ 

strupr (Pri nterOescrl pt i onF 1 1 eNaae ■ iargv[1](slzeof(Kwd3) - 1]); 
continue; 

) 

) 

if (strltn(ergv[f]) >» si zeof (fcrff) ) 

{ 

if (!aea)rtp(argv[i}, Kwd4, sizeof(*wd4) * 1)) 

{ 

SttlogFi I eneae(Aargv(1 ] [$i teof (Kwd4) • 1]); 
continue; 

) 

) 

if (str1en(argv[i)) >■ siztof(Kwd5)) 

{ 

if (!aeBic*)(argv[1], Kwd5, sizeof(Kwd5) - 1)) 

{ 

strupr (targv(1 ) ($1 ieof [Xwd5) -1]); 

if ( (orgy [l ] (si zeof (Kwd5) - 1} >■ ‘A’) U (argv{1 } [si z*of OCwdS) - 1] <■ *Z’)) 
"InstallationDHve * orgv[i]tsiieof(Kwd5) * 1]; 
continue; 

) 

} 

if (strlen(argv[lj) >■ sizeof(KwdG)) 

{ 

if (taealcap(argvfi), Kwd6, si zeof (I(wti8) >1)) 

{ 

struprUorgv[lHsizeof(KwdS) - 1]); 

if ( (argv [ 1 ) [si ztof (Xwd6) - 1] >• 'A') U (argv[l]ls1zeof(KwdS) - 1] <• *Z*)} 
•TargetOHve » ar8v[i]tsiztof(«wd6) • !]; 
continue; 

) 

) 

spri nt f (Buffer* st rl cn (Buffer) , "Unknown Keyword encountered, ‘Is’, Ignored. \n",argv[i)) 

) 

/* Set up Target directory •/ 

spri nt f (T arget Dl r, "lc :\\0S2\\0L L " , *Target0r1 ve) ; 

if (Buffer[0)!«*\$*) (ieg(-l, Buffer);) 

f* Bead PRORV.LST and create chained list */ 

if ({PrinterOrivers • SetOriverMaaes (Driven I stfileKaae)) *« (PPRDRV)KULL) 
exit (1): 

/* Read PRDESC.IS1 end create chained list V 

if ((PrlnterOesc ■ GitPHnterBescHptions(PHnterD«scr1pt1onFl1tKai3E}) ■« 

(PPRDRV)NULL) 

exit (1 ) p 

#if defined (DEBUG) 

«if defined (OEBUG_C«AIN) 

/* Print contents of printer driver chain •/ 

( 

PPRDRV Printer; 

pH ntF("Contents of printer driver chat n:\n\n"); 
far (Printer ■ PrinterOrivers; 

Printer !• (PPRflRV)KUU; 

Printer « Printer->nent) 

( 

pH ntf ("Driver; %s» Key; Is, Disicnua: ld\n", PHnter->drvnase, 

Printer*>Key, Print er*>di SKnua) ; 

) 

printf("\n"); 

) 

fendif 

•endff 

Hf defined(DEBUG) 

Ilf deflned(DEBUG.CHAIN) 

/* Print contents of printer description chain */ 

{ 

PPROESC Oesc; 

pH ntf( "Contents of printer description chal n:\n\n”); 

for (Dtsc » PHnterOesc; 

Oesc 1« (PPROESC) HULL; 

Disc ■ Oesc*>nixt) 

( 

printf ("Drivers is. Key: ls\n- Oesc: ls\n", Desc->drvnane, 

Qesc*>kiy, Oeicodfsc); 

) 

printf("\n*J; 

) 

lendif 

fendif 

if ((Responselnfo » ReadResponssFiletResponseFtt eNaae, PHnterOesc)) •• 

(PRESPONSE.INFO)NUU) 

e*it(l); 

/* Install printer drivers */ 

Instal 1 OH vers (Responselnfo, PrinterOrivers, PrlnterOesc, Install at ionDHve); 
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/* Install printers •/ 

Install Printers (Response Info. PrinterOrivers. PrinterQesc); 
/* Instoll queues V 

I nst el 1 Queues (Responselnfo. PHnterOesc); 

f* Set default pri nter/ queue */ 

SetOef aults (Responselnfo); 

/* Set communications port *f 
SetConmPort (Responselnfo->PortOef) ; 



exit (8); 

) 

/* Read Driver List and create chained list •/ 

/* V 

/* PPRORV GetOri verNaces (PCKAR) ; */ 

i* */ 

/* Parameter: */ 

/• V 

/• PCKAR Filename of Printer Driver list */ 

/* V 

/* Return: */ 

/* V 

/* PPRORV Pointer to chained list V 

/• V 



PPRORV GetOri v erN ernes (P CHAR Filename) 

{ 

FILE •Stream; 

char 8uffer[2893; 

PPRORV PrinterOrivers • (PPRDRV)kULI; 

PPRORV PrinterOrivtrStruCt; 

PPRORV PrinterOriver; 

char •OriverKane; 
char *OiskNua; 

char *Temp; 

static char blcsnK (] « " *; 

char key [20 j; 

int sec err ■ 0; 

/« Open File V 

if ((Stream » f open (FileN ace, *r~) ) «« NULL) 

( 

sprintf (Buffer, "Unable to open file \*%s\*", FileNace); 

Log(*l , Buffer); 
return ((PPRORV) NULL); 

> 

/• Read File */ 

uhile (fgets(0uffer. si zeof (Buffer). Stream)) 

{ 

if ((DriverName = strtok (Suffer, blank)) !* NULL) /• Separate drivemame •/ 

{ 

if ((OiskNun - strtok (NULL , blank)) !* NULL) /• Separate diskette * V 

{ 

if (atoi (Di skNum) >0) /* Disk # > 0 ? V 

( 

St rcpy (key, OriverNome); 

Tecp * strtok(key, ".”); 
if (Temp « NULL) 

Temp * DriverName; 

/* Allocate space for the structure and the strings drvneee/key */ 
PrlnterOri verStruct ■ mal loc(sizeof(PRDRV) ♦ 
strl en(Tercp) ♦ 

St rlen (OriverNome) + 2); 

/* Test if no space available */ 
if (Pri nterOri verStruct ■» (PPRORV)NULl) 

( 

mecerr « 1; 
break; 

) 

/* Initialize structure •/ 

oemset((PCHAR)PrlnterDri verStruct, ’VO', sizeof(PRORV)); 

/* Get disk number */ 

PrinterOriverStruct*>disknum « atoi (DiskNun); 

/• set the pointer for string drvneme and copy the name */ 

PH nterOri verSt ruct->drvnace * 

4((PCHAR)PH nterOri verStruct) [si zeof(PRORV)]; 
st rcpy (Pri nterOri verStruct->drvname, Ori verNace) ; 

/• set the pointer for string key and copy the contents */ 

Pri nterOri verSt ruct*>k«y - 

SPrinterOri verSt ruct*>drvnane( st Hen (DriverName) ♦ 1): 
st rcpy (PH nterOri verStruct->key , T emp) ; 

/• Put structure in chained list */ 
if (PH nterOri vers ■■ (PPRORV)NULL) 

PrinterOrivers - PH nterOri verStruct; 
else 
{ 

for (PH nterOri ver ■ PrinterOrivers; 

Pri nterOri ver->next !« (PPRDRV)NULL; 

PrinterOriver • PH nterOri ver-»next); 

PH nterOri ver* >next • PrlnterOri verStruct; 

) 

) 
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) 

} 

) 

fclose(Strean); 

if (tsetse rr) 

{ 

sprintf (Buffer, "Hot enough catao ry to read file Filename); 

log(-l. Buffer); 

retum((PPRORV)NUU); 

} 

else 

if (PrinterOrivers ■■ (PPRDRV)NULl) 

{ 

sprintf (Buffer, "No printer driver information found in file \"%s\"", 
FHeName); 

Log(-l, Buffer): 

) 



retum(PrinterOri vers) : 

) 

/* Read Printer Description list and create chained list */ 

/* */ 

/* PPRDESC GetPrlnterOescriptions(PCHAR): */ 

f* */ 

/* Parameter: «/ 

r V 

/* PCHAfl Filename of Printer Description list */ 

r •/ 

/• Return: •/ 

/' -/ 

/■ PPRDESC Pointer to Chained list “/ 

r v 

/*•*** •*— — - * * — •••— ■ *— ■ -/ 



PPROESC Get Prl nterDescri pt i ons (PCHAR Filchaae) 

{ 

FILE * St ream; 

char Buffer[?88]; 

PPRDESC Print erDescripti ons • (PPRDESC)NUU; 

PPRDESC PrinterDescStruct; 

PPROESC PrinterOesc; 
char •Keypart; 

char "Oriver; 

char "Tenp; 

char Key (148); 

int cteaerr - 0: 

/* Open File */ 

if ((Stream - fopen(Fi1eNacte, "r")) *■ NULL) 

( 

Sprintf (Buffer, "Unable to open file \“%sV. FileNace): 
log(-l. Buffer); 
return ( (PPRDRV j HULL ) ; 

) 



/• Read File */ 

while (fgets (Buffer, si zeof (Buffer), Stream)) 

{ 

if {(Driver - strrchr(Buffer, ■(’)) l« NULL) /* Look for driver name •/ 

{ 

•Driver • ' \0* s 
Ori ver+4 ; 

if ((Temp » st rchr (Driver, )*)) 1- nuu) 

"Temp ■ XB': 

strcpy(Key. Driver); /• Create Key */ 

if ((Temp ■ st rchr (Key, ’.’)) !» NULL) 

•Temp • '\e* ; 



if ((Keypart ■ st rchr (Buffer, 

( 

•Keypart • '\8's 
Keypart +4* 

Strip (Keypart); 



1» null) /• Separate description/ */ 
/• part of the Key for •/ 
/• PH_SP0QIER_09 */ 

/• Eliminate leadlng/t railing blanks •/ 



street (Key, ".“); /• Coaplete Key •/ 

street (Key, Keypart); 

) 

/* Allocate space for the structure and the strings drvnase/Key/desc V 
PrinterDescStruct • ma11oc(sizeof(PR0ESC) ♦ 
strlen(Oriver) ♦ 
strlen(Key) ♦ 

Strlen(Buffer) 4 3); 

/* Test if no space available •/ 
if (PrinterDescStruct ■« (PPRDRV) NULL) 

{ 

memerr ■ i; 
breax; 

) 

/• Initialize structure •/ 

memset( (PCHAR) PH nterOescStruct, ‘XB 1 , sizeof(PROESC)); 



/• set the pointer for string flrvncae and copy the name •/ 
Pri nterOescStruct ->drvnace - 

* ( (PCHAR) PH nterOescStruct) (si zeof (PROESC) ] ; 
strcpy(PrlnterOescStruct->drvname, Oriver); 
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/* Set the pointer for strfng key and copy V 

PrlnterOesc$truct»»key • 

IP rinterOescStruct*>drvnane(strlen (Driver) ♦ 1]; 
strcpy(PHnterOescStruet->key, Key)} 

/* set the pointer for string desc and copy the description */ 
PrinterBescStruct->desc « 

SPr1nterBe$cStruct‘>ksy[str)en(Key) ♦ lj; 
strcpy (PH merOe sc Struct *>desc, Buffer) ; 

/* Put structure in chained list V 
if (PrinterOescriptions (PPROESC) NULL) 

PrlnterOescriptions * PrinterOescStruct; 

else 

{ 

for (PrinterOesc * PrinterOescriptions; 

PrinterCesc->next !■ (PPROESC) NULL; 

PrinterOesc ■ PrinterCesc->next); 

PrlnterOesc->next • PrinterOescStruct; 

) 

) 

) 

fclose (Street)); 

if (aenerr) 

{ 

sprintf (Buffer, "Hot enough xtaory to read file \"ls\"\ FlleNase); 

log(*l, Buffer); 

rtturn((PPRORV)NULl); 

> 

else 

if (PrinterOescriptions «* (PPRORV) Null) 

( 

sprintf (Buffer, ‘ho printer info found in file \"%s\", Fil thane); 
log(*l. Buffer); 

) 

retum(PrinterDescri pti ons) ; 

) 



y*»**«*M«*«a*a*«*fttt«**»*********»**1lft*ft*IM»«ft***»********M****«***»***»****/ 
/* EH ni note leeding/trailing blanks of a string */ 

/• V 

/* PCKAR Strip (PCHAR); */ 

t* V 

/" Parameter: »/ 

/* V 

/• PCKAR String V 

/* V 

/* Return: */ 

t* V 

/* PCKAR Pointer to string */ 

/* V 

PCKAR Strip (PCHAR String) 

( 

PCKAR Temp; 

SHORT 1 ; 



/* Search for first nonblank character */ 
for (Teep » String; *Teap !« '\6*; T»ep>*) 

( 

if (Mecp !- ■ ■) 

{ /* First non-blank found V 

if (Tt«p !* String) /* cove if leading blanks V 

ntnwve (String, Teap, strltn(Tetmj) ♦ 1); 

for (i ■ st rlen (String) * 1; 1 >■ 6; l—) /* Eliminate trailing blanks */ 

( 

if ($tr1ng(1] •« • *) 

String(i) ■ *\B'; 

else 

break; 

> 

break; 

) 

) 

ret urn (St ring); 

) 



/* Install printer drivers */ 
f* V 
r VOIO Install OH vers(PRESPOKSEjKFO, PPRORV, PPROESC, PCKAR); V 
t* ~ V 
/* Paraaeter: «/ 
/" V 
/• P RESPONSE Response file Information */ 
/« PPRORV Chained list of printer drivers •/ 
/* PPROESC Chained list of printer descriptions */ 
/* PCHAR Installation drive V 
/* V 
/* Return: */ 
/* V 
/« none •/ 
/• V 
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{ 

static 

static 



VOID InstallOrWers(PR£SPOWE_Ii*FO Responselnfo, 

PPRORV PrinterDrWers, PPROESC PrinterDesc, 
PCHAR JnstDrWe) 

Cher pn_device_drivers[] • "PMJIEVICEJJRIVERS"; 

char pn spooler dd[] - "PM SP001ER.DD"; 

SHORT 1 

PPRINTERDEF PrtDef « R*sponseInfo*>PrinterOef; 

PPRTORVOEF PrtOrvDef; 

PPROESC PrtOesc; 

PPRORV PrtOrv; 

USHORT DISK • 0; 

CHAR Massage [BO]; 

CHAR Value [30]; 

BOOL Install PI otter > FALSE; 



/* First flag all printer descriptions we have to Install V 
for (i « 0; 1 < MAX PRINTERS; U*) 

{ 

if (PrtOef [1 ) .DrvInfoLi ne > NOT DEFINED) 

{ 

for (PrtOrvDef ■ Prt0ef[1].DHv«rlnfo; 

PrtOrvDef !« (PPRTORVOEF] NULL; 

PrtOrvDef ■ PrtOrvDef->next) 

{ 

GetDescByKucber(PrlnterOese, PrtOrvOef->index)->lnstFlag • TRUE; 
f* PrtOesc->!nstFlag • TRUE; •/ 

) 

) 

} 



/• Flag all printer drivers we have to Install V 

for (PrtOesc ■ PrinterDesc; PrtDesc !» (PPROESC) NULL; PrtOesc • PrtOesc->next) 

{ 

if (PrtOesc“>InstFlag) 

{ 

If ((PrtOrv • 6et0rlver8yNaBe(Prlnter0rlvers, PrtO»sc*»drvnaae)) !■ 
(PPRORV) NULL) /* Set DRIVER STRUCTURE */ 

{ 

PrtOrv*>InstFlag • TRUE; 

If ( I strl cap (PrtOrv*>drvname, "PLOTTERS. ORV")) 

Install PI otter « TRUE; 

) 

) 

} 



/* Mara all drivers previously Installed */ 

Maralnstal 1 edOri vers IPH nterOri vers) ; 

/* Now install printers "/ 

for (PrtOrv » Prl nterOri vers; PrtOrv !- (PPRORV)NULL; 

PrtOrv » PrtOrv->next) 

( 

/* If PLOTTERS.DRV used, check for PMPLOTPD.ORV */ 
if Clnstal 1 Plotter) 

If (! stri cop (PrtOrv >drvnaoe, "PMPLOTPO.ORV")) 

PrtOrv*>InstFl ag • TRUE; 

if (PrtDrv->InstFlag) 

{ 

if ("InstOrive <• *0') 

If (Oise r» PrtDrv>disanuo) 

{ 

Disk ■ PrtOrv->distcnun; 

printf ("Insert printer driver diskette f %d " 

"In drive %c:. then press any k«y.\n", Disk.MnstOrivt); 
If OsetchO) 
setch(); 

) 

sort ntf (Message, "Installing printer driver %s ...", PrtDrv-»drvRa«e5; 
Log(-l, Message); 

if (! Install Prl nterOri ver (PrtOrv, InstDrive)) 

{ 

spri ntf (Message, "Installation of %s failed.", PrtOrv->drvnaae) ; 
PrtDrv-»lnstF1ag • FALSE; 

) 

else 

spri ntf (Message, "Installation of %s cospleteo with no error.", 
PrtOrv->drvne=e) ; 

Log{-l, Message); 

) 

) 

/* Now update the OS*. INI */ 

Log(-l, "Updating OS*. INI..."); 

for (PrtOrv • Pri nterOri vers; PrtDrv !■ (PPRORV) NULL; 

PrtOrv » PrtDrv->next) 
if (PrtOrv->JnstFlag) 

PrfVri teProfi 1 eString(HlNI_USERPROFIlE, 
ps_devi ctjlrl vers, 

PrtDrv->key, 

PrtOrv->value); 



1* Now update the OS2SYS.INI •/ 
log(“l, ‘Updating OS2SYS.INI..."); 

PrtOesc ■ PrinttrOesc; 
for (PrtDesc ■ PrinterDesc; 

PrtDesc I- (PPROESC) NULL; PrtOesc - PrtOesc->next) 
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{ 

if (PrtDesc->InstF1ag) 

{ 

/• First Iook, if printer driver installed an V 
for (PrtOrv - PrinterDrivers; PrtQrv l» (PPRDRV)NULl; 

PrtOrv - PrtDrv->next) 

if (!stricei)(PrtOesc->drvnace, PrtOrv->drvnace)) 

{ 

if (PrtOrv->jnstFlag) 

{ 

strcpy (Value, PrtDrv->drvnane); 
street (Value. "j;;"); 

PrfWri teProf 1 1 eSt ri ng(H!Nl_SYSTEMPROF I Ll . 

pa spooler dd, PrtBesc-my, Value); 

) 

) 

) 

) 

) 



/" 








/* 


Install printers 




*/ 


/* 






"/ 


/* 


V0I0 Install Printers (PRESPONSEJNFO. PPRORV, PPROESC); 


-/ 


/* 






*/ 


/- Paraceter: 




*/ 


/" 






V 


/* 


PRESPONSE 


Response file information 


V 


/• 


PPRORV 


Chained list of printer drivers 


-/ 


/* 


PPROESC 


Chained list Df printer descriptions 


*/ 


/" 






«/ 


/* 


Return: 




V 


/* 






V 


/* 


none 




*/ 


r 






V 


/*• 










VOIO 


I nst al 1 Pri nt ers (PRE SP0NSE_I NF 0 Re sponse I nf o , 




/ 




PPRORV PrinterDrivers, PPROESC PrinterOesc) 


static PRDI NF 03 


prdinfo3; 






PPRINTERDEF PrtDef • ResponseInfo-*PrinterDef; 






SHORT 


i; 






CHAR 


Destination[10); 






PPRTORVDEF Drvlnfo; 






PPRDESC 


PrtDesc; 






USHORT 


re; 






PPRORV 


PrtOrv; 






CHAR 


Message [128]; 





Lag(»l, "Installing printers.. 
far (i - 0; i < KAX PRINTERS; i++) 

{ 

if (PrtDef [i).0rvlnfaline > NOT DEFINED) 

{ 

/• First get the driver info V 
•Buffer • *\8* ; 

for (Drvlnfo * PrtDef[i).Driverlnfo; 

Orvlnfo !* (PPRTQRVDEF)NyU; 

Drvlnfo * Orvlnfo->next) 

{ 

/- Get printer description structure -/ 

PrtOesc ■ CetOescByNucber(PrinterDesc, QrvInfo->index); 

/- First loox, if printer driver installed ck */ 
if ((PrtOrv * GetDriverByNaoe(PrinterOrivers, PrtOesc->drvnare)) !» 
(PPRTDRVDEF)NUIL) 

( 

if (PrtDrv->lnstFlag) 

{ 

if (-Buffer) 

street (Buffer, ","); 
street (Buffer, PrtOesc->xey); 

) 

} 

} 

if (! -Buffer) 

( 

sprintf (Buffer, "Printertd \*Ns\" will not instoll because printer" 

H driver didn't install’ - , i + I, PrtDef[l].Narse); 
PrtOef[i].Drvlnfoline » PrtDef(i). Port Line « PrtQef[i].Nanetine - 
PrtDef(i).Descline ■ INSTAu.ERRQR; 

Log(-l, Buffer); 
continue; 

) 

prdinfoS.DSZPrinterNeae * (PSZ)PrtOef [i Mace; 
prdinfo3.psniserNene * (PSZ)NUIL; 

sprintf (Destination, **s*u". (PrtDlflt) .Port[B] ■» 't‘ ? "LPT" ; "COM"), 
(USHORT)(UCHAR)PrtDef(i).Port(l)); 
prdinfo3.psiLogAddr » (PSZ)Destination; 
prdinfo3.uJobId * 0; 
prdi nf o3 . f sStatus * 0; 
prdinfo3.pSZStatus - (PSZ)KUll; 
prdinfo3.pszCccoent » (PSZ)PrtOef(lJ.Description; 
prdinfoS.pszDrivers ■ (PSZ)Buffer; 
prdinfo3.tice * prdinfo3.usTite0ut » 0; 

#ff defined(OEBUG) 
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Log(-l, ‘before DosPrintDestAdd..."); 

#endi f 

rc > DosPr 1 ntOestAdd ( (PSZ ) NU L L , (USH0RT)3, (PBYTE)4prdinfo3. si zeof (PRDINF03)) ; 
#if defined(QEBUG) 

Log(-l, "after OosPri ntOestAdd..."); 

fendi f 

if (rc) 

{ 

sprint f (Message, ‘Cannot create Printertd rc ■ %d", i + 1, 

( PSZ )PrtOef(iJ. Name, rc); 

Log(-l, Message); 

PrtOef [i ].NaoeLine ■ PrtDef [iJ.DrvInfoiine • PrtDef[i J.PortLine « 

PrtDef [ij.OescLine » INSTALL ERROR; 

) 

else 

{ 

sprlntf (Message. ‘Printer \"*s\" created successfully", (PSZ ) PrtDef [i ).Neme); 
Log(-I , Message); 

) 

) 

) 

) 



/*— — * * «••**/ 

/* Install queues •/ 

f* •/ 

/* V0I0 Instn1lQueues(PRESP0NSE INFO, PPROESC); */ 

f* •/ 

/* Parameter: */ 

/* V 

f* PRESPONSE Response file information */ 

/* PPROESC Chained list of printer descriptions */ 

r V 

/* Return: «/ 

/* V 

/* none »/ 

/* V 

/***”* - — — 



VOID Install Oueues(PR£SPONSE_INFO Responselnfo, 

PPROESC PrinterOesc) 

( 

static PR0INF03 prqinfo3; 

PQUEUEOEF OueueDef • ResponseInfo->QueueOef; 

SHORT i ; 

PPRT_CONN PrtConn; 

SHORT Driverlndex; 

PPRTORVOEF PrtOrv; 

PPROESC PrtOesc; 

USHORT rc; 

Log(-l, “Installing queues..."); 
for (i • 0; i < MAX QUEUES; i+*) 

( 

if (OueueDef [i]. New Line > NOT DEFINED) 

{ 

/* Initialize structure */ 

ceoset ( (PCHAR)4proi nfo3, AG', sizeof (PR0INFO3)) ; 
prq { nfc3.pszNaw * OueueDef [i j. New; 
prqinfo3.uPriority « PRQ_QEF_PR!ORI T Y; 
prqinfo3.pszPrProc - (PSZ) OueueDef [i ] .Queueproc; 
prqi nfo3.ps zComwnt » (PSZ)QueueDef (i J. Description; 

/* Get printernaws/drivernane '/ 

•Buffer « 'Xe*; 

for (PrtConn - OueueDef (i ) .PrtConn; 

PrtConn !• (PPRT_CDNN)NUU; 

PrtConn » PrtConnonext) 

{ 

/• Is printer installed? */ 

if (ResponseInfo->PrinterDef(PrtConn*>Printer - 1] .DrvInfoLine <■ 
NOT.DEFINEO) 
continue; 

f* Add printer name to buffer •/ 
if ("Buffer) 

St rcot (Buffer, ","); 

street (Buffer, ResponseInfo->PrinterDef [ PrtConn* >Printer - l).Name); 

/" If no driver specified yet, tew the first o f this printer •/ 
if (prqinfo3.pszDHverNaw ** (PSZ)NULl) 

Oriverlndex - I; 
else 

Driverlndex • NCT_ DEFINED; 

/* Look, if there is an index for the printer driver •/ 
if (PrtConn.>Oriver > NQTJJEFINED) 

Driverlndex ■ PrtConn->Ori ver; 

if (Oriverlndex > NOT DEFINED) 

{ 

for (PrtOrv ■ ResponseInfo-»PrinterOef ( PrtConn- >PHnter - ll.Driverlnfo; 
PrtOrv !• NULL; PrtOrv ■ PrtOrv->next) 

( 

Driverlndex*-; 
if (Oriverlndex ■« 0) 

{ 

PrtOesc • GetDescByNucber(PrinterOesc, PrtOrv*>index); 

prqinfo3.psz0ri verNaw » PrtOesc*>xey; 

breex; 

) 

) 
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} 



) 

If (-Buffer) 

( 

prqinfoS.pszPrinters « Buffer; 

•if defined(OEBUG) 

leg(-l, ‘before DosPrintQAdd...“); 

•endi f 

rc ■ OosPrlntQAdd((PSZ)KULL, (USH0RT)3, (PBTTE)tprqinfo3, si x«of (PROI MF 03) > ; 
•if defined (DEBUG) 

Log(-l t “after DosPrintOAdd...*); 

•endi f 

if (rc) 

{ 

sprintf (Buffer, “Error %d while creating queue *s", rc, prqinfoS.pszNaite) ; 
log(*l, Buffer); 

) 

else 

( 

sprintf (Buffer, “Queue \”%s\“ created successfully*, 
prqi nf o3.pszNace) ; 

Log(-l, Buffer); 

) 

) 

else 

{ 

sprintf (Buffer, “Oueueid did not install because of problens In • 

■printer installation*, 1 ♦ 1); 
log(*l, Buffer); 

) 

) 

) 

) 





/* Set default printer/queue V 
/- V 
/* VOID SetOef ault s ( PRE SP ON $£_ I NF 0 ) ; */ 
/* " V 
/* Parameter; •/ 
/* V 
/* PRESPONSE Response file information •/ 
/. •/ 
/* Return: V 
/* V 
/* none »/ 
/* V 




VOID SetDefaultS (PRESPONSE INFO Responselnfo) 

{ 

CHAR Buffer [188); 

SHORT Index; 

Static CHAR seoixolonf] * 

Static CHAR PM_ SPOOLER!) ■ *PM_ SPOOLER*; 

if (ResponseInfo*>DtfPrtline > INSTALL ERROR) 

{ 

Index * ResponseInfo»»DefaultPrinter - 1; 

if (Responselnf o->Pri nterOef [Index] .Name Li ne INST All ERROR) 

( 

sprintf (Buffer, 

“Cannot cefine default printer because Printer%d didn't install". 
Index ♦ 1); 

LogC-1 » Buffer); 

) 

else 

if (ResponseInfo*>PrinterDef(Index].NeseLine > NOT DEFINED) 

{ 

st rcpy (Buffer, ResponseInfo->Pri nterOef [Index] .Name) ; 
street (Buffer, semi Ml on); 

PrfWri teProf i l eStri ng (HI NI.USERPROFRE , 

PH_SP00LER, 

“PRINTER*, 

Buffer) ; 

tog(-l, "Default printer installed.*); 

) 

else 

( 

sprintf(Buffer, 

“Cannot define default printer, definition of Printertd in error*. 
Index ♦ 1); 
log(-l. Buffer); 

) 

) 

if (Res p on se I nfo->Def Outline > INSTALL ERROR) 

( 

Index • ResponstInfo*>OefaultOueue * I; 
if (ResponseInfo->QueueOef [Index]. Nestline ■■ INSTALL ERROR) 

( 

sprintf (Duffer, 

“Cannot define default queue because Oucue%d didn't install “• 

Index * 1); 

Log(-l, Buffer); 

) 

else 

if (ResponseInfo->Ou«utOef [Index]. Naotline > NOT DEFINED) 

{ 
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strcpy (Buffer, ResponseInfo->Q U eueDef [Index] .Kane] ; 
streat (Buffer, seni kol on) ; 

PrfWH teProfi 1 eStri ng(H!Nl_USERPROFI LE, 

PM_ SPOOLER, 

"QUEUE", 

Buffer); 

Log(-l, -Default queue installed."): 

) 

else 

{ 

sprintf (Buffer, 

-Cannot define default queue, definition of Queue%d in error’ 1 . 
Index ♦ 1); 
log(“l. Buffer); 

} 

) 

) 



/* Set cowaunl cation ports definitions */ 
/* V 
/* V0I0 SetCoraPort (PPQRT_BEF ) ; */ 
t* ~ V 
f* Paraneter; */ 
/- V 
/• PP0RT_0£F port definition table •/ 
/“ V 
/* Return; */ 
/* */ 
/• none •/ 
/• V 



VOID SetCocnPort(PPORT DEF PortDef) 

{ 

SHORT 1 ; 

CHAR Buffer[B0]; 

USHORT Parity; 

static PCHAR StcpBitsTableO • 

{ 

- 1 -, 

"2". 

); 

CHAR Port [10]; 

for (i • 0; i < KAX COM; i**) 

{ 

if (Port Oef(i). Line > ROT OEFIREO) 

( 

if (PertOef[i]. Parity - ’(T) 

Parity * 0; 

else 

if (PortDef [i]. Parity «• ’O’) 

Parity * 1; 
else 

Parity « 2; 

spri nt f (Buff er, *%u;%u;%u;%s;%u; * , 

PortDef [iJ.BaudRate, 

Parity, 

PortDef fll.DataBits, 

StopBi tslabl e[ (USHORT) (UCKAR) (PortDef [i ) .StooBi ts - ’A')], 
(PortOef[i]. Handshake •• ? 1 ; 0)); 

i f (PrfVri teProf i 1 eStri ng (HI HI_SYST EWRQFI LE , 

•PM_SP00LER_PQRT\ 

Port, 

Buffer)) 

sprlntf(Buffer, "Definition for cecauni cations port %d oade", i + 1); 

else 

sprintf (Buffer, -Error while defining contauni cation port %d”, i + 1); 

log(-l, Buffer); 

) 

) 

} 



*— */ 

/• Get infomation about installed printers froa 0S2SYS.INI */ 

/• ./ 

/* VOID Mark InstalledDri vers (PPRDRV); •/ 

r V 

/* Peraseter: »/ 

/* “/ 

/* PPRDRV Printer driver chain -/ 

/* */ 

/■ Return: */ 

/• V 

/" none */ 

t* V 

/“*• — — * — — — — *— — */ 



V0I0 Maral nstal 1 edOr i vers (PPRORV PrinterDrivirs) 

{ 

static CHAR pnjlevice drlvers() • "PM DEVICE DRIVERS"; 

10RG ten; 

PCKAR Drivers; 

CHAR Ha*e[20]; 

PPRDRV OriverStruct; 
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Len- 64639; 

If ((Drivers - nal 1 oc( (SHORT } Len) ) »» NULL) 
return; 

steoset (Drivers, •Xfl*. (SHORT) Len); 

PrfQueryProfileString(HlNI_PROFILE, pajlevice_drivers, NULL, NULL, Orivers, 
ten); 

far (; "Drivers !» *X0‘; Orivers +* (st Hen (Orivers) ♦ 1)) 

{ 

sprint f(Nene. "%s.DRV‘’. Drivers); 

If ((Dri verSt ruct « GetOri verflyNaise (Print erOri vers, Kara)) !» (PPRORV)NULl) 
Ori verS t rue t*>Inst Flag - TRUE; 

} 

free (Dri vers); 

) 



H.7 C Source for RESPONSES 

This module reads the printer response file and provides the necessary analysis 
of this file. 



/* Read response file and do the syntax checking V 

/**************************** A********************* ********************«•******/ 

•include <stdlib.h> 

•include <stdio.h> 

•include <string.h> 

•include <«etsory,h> 

•include <ctype.h> 



•include <os2.h> 

•include "rinstprn.h" 

•include "r_error.h" 

Static ERROR.STRUCT ErrorTebl e(KWiJRRORS) ; 

Static USHORT ErrorCount; 

/* Declaration of internal functions in this nodule */ 

int cded SortErrcrT abl e (voi d "Errorl, void *Error2); 

VOID Get Print erPort (PPRI NTERDEF PrinterOef, PC HAR Value, 

SHORT Nutter, USHORT LineNuttPer); 

BOOL GetPrinterOHvers(PCKAR Value, PPRINTERDEF PrinterOef, 

PPRDESC Print erOesc, USHORT LineNuiaber); 
VOID Get AddPH nterOri vers(PCHAR Value, PPRDESC PrinterDesc, 

USH0R T LineNunber); 

VOID Get PrinterNaire (PPRINTERDEF PrinterOef, PC HAR Value, 

USHORT llneNuiBber, SHORT Number); 

VOID GetOueueNace(POUEuEDEF QueueOef, PC HAR Value, 

USHORT LintNucber, SHORT Nusber); 

BOOL Get PrinterConnect ions (PCHAR Value, PQUEUEOEF QueueOef, 

USHORT LineNucfaer); 

VOID GetCoB=PortDefinitlcn(PCKAfl Volue. PP0RT_QEF PortOef, 

USHORT LineNucber, PCHAR Keyword); 



I* Read Response file and create tables and chained lists */ 

/* V 

/" PRESPONSE INFO ReadflesponseFi 1 e (PCHAR, PPRDESC); */ 

f* *f 

f* Paratteter: */ 

/* V 

/* PCHAR Filename of Response file V 

/* PPRDESC Chained list of printer descriptions V 

/* •/ 

/* Return: V 

f* V 

/* PRESPONSEJNFO NULL • taenory error V 

/* Or •/ 

/* Pointer to RESPONSE INFO structure */ 

i* */ 



/* Author: Gert Ehing Deeetber 1991 ITSC Boca Raton, Florida "/ 

/*•*.*.**.* ********** ************************************/ 

PRESPONSE INFO ReadResponseFile (PCHAR FileNaee, PPRDESC PrinterDesc) 

{ 

FILE "Streen; 
char Buffer[2B8]; 

char Error(269); 

int l, j; 

USHORT lineCount; 

SHORT rc; 

PCHAR Keyword; 

PCHAR Value; 

static PCHAR Keywords [) « 

< 

-PRINTERDESC", 

■PRINT ERKAME-, 

■PRINTERPORT", 
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"PRINTER", 

"QUEUEOESC". 

"QUEUENAME", 

"GUEUEPROC", 

"QUEUE", 

"COWPORT", 

}; 

static PCHAR QueueProcsH « 

( 

"PKPRIHT", 

"PMPLOT", 

): 

static CHAR OefaultPrinterf] • "QEFAUITPRINTER"; 

static CHAR Default Queue [] ■ "QEFAUITQUEUE"; 

static CHAR Additional Printer [] - "AODJTIONAIPRINTER"; 

static CHAR blame!) * * 

Static PCHAR ErrerMsgf] ' 

{ 

l* Error # 0 */ "Syntax error in line %d of " RSP 

/* Error f 1 •/ "Invalid Keyword Is in line Id of ' RSP 

/* Error 9 2*/ "Invalid printer port Is defined in line Id of " RSP 

/* Error 13*/ "Printer port Is, line Id of " RSP " ignored:", 

/* Error 9 4 */ "Duplicate definition for Is in line Id of ° RSP " ignored:", 

/* Error f 5 */ "Duplicate definition for Is in line Id of * RSP * ignored:", 

f* Error » 6 V "Non-numeric My value Is in line Id of * RSP * ignored:*, 

/* Error 91*/ "Invalid Myvalue Is in line Id Df " RSP " ignored:", 

/* Error 9 6 */ "Duplicate Myvalue in line Id of " RSP * ignored:", 

/* Error 9 9 */ "Duplicate printer description in line Id of " RSP " ignored:", 

/* Error 9 19 */ "Duplicate definition for Is in line Id of * RSP * ignored:", 
r Error 9 11 •/ "Printer none truncated to Is in line Id of " RSP 

/• Error 9 12 */ "PrinterNanels, line Id of " RSP " ignored:", 

/* Error #13*/ "Duplicate queue description in line Id of " RSP * ignored:", 

/* Error 9 14 */ "Duplicate definition for Is in line Id of " RSP " ignored:", 

/* Error 9 15 */ "Queue name truncated to Is in line Id of " RSP 

/* Error 9 18 */ "Queue name Is in line Id of " RSP " already defined, line ignored:", 

/* Error # 17 */ “is already defined, line Id of “ RSP " ignored:", 

/" Error 9 IB */ "Invalid queue processor Is in line Id of * RSP ", line ignored:", 
f* Error 9 19 */ "Invalid parameter in line Id of " RSP ", line ignored:', 

/* Error 9 20 */ ‘Non-numeric printemueber is in line Id of " RSP ", line ignored:", 

/* Error 9 21 */ "Non-numeric drivemueber Is in line Id of " RSP ", line ignored:", 

/" Error f 22 */ "Invalid print emumber Is in line Id of " RSP ", line ignored:", 

/* Error 9 23 */ “Invalid drivemueber Is in line Id of " RSP ", line ignored:", 

/* Error 9 24 */ "Queue- connection to Is in line Id of " RSP " already defined, line ignored:", 

/* Error 9 25 "/ "Duplicate definition for Is in " RSP ", line Id ignored:', 

/* Error 9 26 */ "Non-numeric baud rate for Is, line Id of " RSP " ignored:", 

/* Error 9 V *f "Invalid baud rate Is, line Id of " RSP " ignored:", 

/* Error 9 28 */ "Invalid parity value Is, line Id of “ RSP " ignored:", 

/* Error 9 29 •/ "Non-numeric data bits value for is, line Id of * RSP " Ignored:", 

/* Error 9 30 */ "Invalid data bits value Is, line Id of * RSP " Ignored:", 

/" Error 9 31 */ "Invalid stop bits value Is, line Id of * RSP " ignored:’, 

/* Error 9 32 */ "Invalid handshake value Is, line Id of " RSP " ignored:", 

/* Error 9 33 V “Is not defined, line Id of * RSP ’ ignored:’, 

/* Error 9 34 •/ "Generated Print erN artels, line Id of " RSP " ignored:", 

/* Error 9 35 */ "Cannot connect Queuels (printer undefined), line Id of " RSP “ ignored:", 

/* Error 9 3$ */ "No valid connections for Queuels, line Id of " RSP " ignored:", 

/• Error 9 V */ "QueueNamels, line Id of " RSP " ignored:", 

/* Error 9 3B */ "Generated QueueKamels, line Id of " RSP " ignored:", 

/* Error 9 39 V “Is not defined, line Id of " RSP " ignored:', 

/* Error 9 40 */ "Definition of Is in error, line Id of " RSP " ignored:", 

/• Error 9 41 •/ "Invalid value Is for default printer, line Id of ’ RSP " ignored:", 

/* Error 9 42 */ "Invalid value Is for default queue, line Id of " RSP " ignored:’, 

/* Error 9 43 */ "Printer name Is already defined by previous install at ion,\n1 ine Id of " RSP " ignored:", 

/* Error 9 44 */ "Generated printer name Is already defined by previous installation,\nl ine Id of ’ RSP " ignored:", 
/* Error 9 45 •/ "Printer port Is already defined by previous install ation,\nl ine Id of " RSP " ignored:", 

/* Error 9 46 */ "Queue name Is already defined by previous installation,\nl ine Id of " RSP " ignored:”, 

/* Error 9 47 */ "Generated queue name Is already defined by previous instal loti on,\nl ine Id of ’ RSP " ignored:", 

); 

SHORT KeyNr; 

SHORT Number; 

static PR1NTERDEF PrinterDef(KAX_PRINTERS]; 

static QUEUEDEF QueueDef (KAX_GUEtlES) ; 

static P0RT_DEF PortOef (MAX.COM) ; 

static RESPONSE INFO Responselnfo « /• Whole response information structure */ 

( 

PrinterDef, 

QueueDef, 

PortOef, 



N0T_0EFINE0. 

NOT OEFINEO 
); ' 

/• Initialize Printer definition table */ 
oenset( (PCHAR) PrinterDef, '\0’, si zeof (PRINTERDEF)); 

PrinterDef (0).DrvInfoline « PrinterDef [0] .Portline ■ 

PrinterDef [0]. Nameline • PrinterDef [0).Oescl ine « NOT_QEFINED; 

for (i - 1; i < KAX_PRINTERS; U*) 

MEcpy((PCHAR)4Printer0ef[i), (PCHAR) PrinterDef. si zeof (PRINTERDEF)); 

/• Initialize queue definition table */ 
cosset ( (PCHAR) QueueDef, '\8* t si zeof (QUEUEDEF)); 

QueueDef (0).NameLine « QueueDef (8). Gueueprocline - 

OueueOef(0] .DtscLine > N0T0EFJNE0; 
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for (1 • 1; \ * KAX_ QUEUES; i**) 

M«py((PCHAR)SQu*usBef[i], (PCHAR)QueueOef, si zeof (QUEUEDEF)); 

/* Initialize port definition table »/ 

■emset ( (PCKAR)PortOef * ’\0’. s1z*of(P0RT_DEF)) ; 

PortOef [8] .Li nt » NOTJJEFIKEO; 

for (1 « 1; 1 < MXCOK; i**) 

aencpy ( (PCKAR)tPortOef [i ] , (P CHAR) PortOef. si zeof(PORTjJEF)) ; 

/• Open Response File V 

if ((Stream ■ fopen(FiltName t "r“)) «• HULL) 

{ 

sprfntf (Buffer, "Cannot reed response file \"%s\"", FileNane); 

Log(-l, Buffer); 
retum((PRESPONSE INFO) NULL}; 

) 

log(*I, 'Analizing printer response file..."); 

LineCount « ErrorCount « 8; 

while (fgets(6uffer, si zeof (Buffer), Strean)) /* Read response file */ 

t 

LineCount**; 

Bufferlsl zeof (Buffer) • 1] • '\0'; 

if (Buffer [1 ■ (strlen (Buffer) - 1)) '\x6A*) /* El ini note l/F */ 

8uffer( 1) . *\e*; 

if ({‘Buffer t« **') 14 (‘Buffer 1« '\9')) /• test for espty or •/ 

{ /* consent line •/ 

/‘ Separate Keyword end value •/ 
if ((Value ■ strchr(Buffer, *-*)) «« NULL) 

{ 

/* *■' not found, invalid line In response file V 
AddError( LineCount, JKVALID_LINE, NULL); 
continue; 

) 

•Value ■ '\0‘: 

Value**; 

Keyword » Buffer; 

/* Eliminate leadlng/trai ling blank in keyword ■/ 

Strip (Keyword); 

/* Eliminate leadtng/trail ing blanks in value ■/ 

Strip (Val ue); 

/• Test Parameter •/ 
if (‘Value *\fl‘) 

( 

AddError(iineCount, INVALID.LIKE, NULL); 
continue; 

) 

/‘ Check the keywords */ 

Keyhr » Number « -1; 

if (! st ri cmp (Keyword, OefaultPrinter)) 

( 

Key Nr • KEY OEFAULTPRINTER; 

) 

else 

if (1 strict® (Keyword, DefaultQueue)) 

{ 

KeyNr • KEY DEFAULTQUEUE; 

} 

else 

if (lstrlcnp(Keyword, Additional Printer)) 

( 

KeyNr • NEY AQDITIONAlPRT ; 

} 

else 

for (1 • 0; i < (si zeof (Keywords) / slzeof(PCHAR)); »♦♦) 

{ 

if (strlen (Keyword) > (j » strlen (Keywords(i)))) /* test length */ 

( 

if ( ( neni cap (Keyword , Keywords!!], j)) /* test keyword ‘/ 

( 

/• Keyword found */ 

Number ■ atoi (4Keyword(j)); /* Get number in keyword •/ 

/* Test Number */ 

if (i <« KEY PRINTER) /* Printer... keyword? */ 

{ 

/* If number < 1 or > MX_PRINTERS — > Error */ 
if ((Number < 1) I) (Number > MX PRINTERS)) 

{ 

break; 

) 

) 

else 

if (i <• KEY QUEUE) /* Queue... keyword? */ 

( 

/• If number < 1 or > MXJJUEUES -•> Error */ 
if ((Number < 1) II (Number > KAX QUEUES)) 

{ 

break; 

) 

) 
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else /* Consportx Keyword */ 

/* If nuiaber < 1 or > MAX_CCM --> Error •/ 

If ((Number < 1) II (Number > MAX COM)) 

{ 

break; 

) 

KeyNr » i; 
break; 

) 

) 

) 

If (KeyNr «*• *1) /* Fehler? --> Invalid Keyword •/ 

( 

AddError (lineCount. INVALID_KEYW0R0, Keyword); 
continue; 

) 

switch (KeyNr) 

( 

cose KEY.PRINTERDESC: 

/• Test, If printer description already defined */ 
if (PrinterOef [Number * lj.Oescline !« -1) 

( 

AddError(LineCount, 0UPLICATE_P0ESC, Keyword); 
break; 

) 

st mcpy(PrlnterDef[ Number • 1). Description, Value, 

DESCRIPTION LENGTH - 1); 

PrinterDefl Number -’l].Qescription[OESCRIPTION_LENGTH - 1) ■ *V9* 

PrinterBef [Number - lj.Oescline - lineCount; 

bream; 

case KEY PftlNTERNAME: 

/• Test, if printer name already defined */ 

If (PrinterDef [Number - 1). Name Line I« -1) 

{ 

AddError ( L i neCount , 0UPLICATE_PRTNAME, Keyword); 
break; 

) 

GetPrinterNane (PrinterOef, Value, LineCount, Number * 1); 
break; 

case KEY_PRINTERPQRT: /* Get printer port definition •/ 

/• Test, if printer port already defined •/ 
if (PrinterOef [Number - lJ.Portline I- -1) 

( 

AddError (LineCount, OUPl I CAT EXPORT, Keyword); 
break; 

) 

CetPri nterPort (PrinterOef, Volue, Number • 1, LineCount); 
break; 

case key_printer: 

/* Test, if printer already defined */ 
if (PrinterOef (Number • l).OrvInfoLine !* -1) 

( 

AddE rror ( Li neCount , DUPLICATE_PRINTER, Keyword); 
break; 

} 



rc ■ CetPrinterOri vers (Value, GPrinterDef [Number -1], 

Print erDesc, LineCount); 

if (Ire) 

ret urn((PRESPONS£_lNFO) NULL); /* If memory error, return */ 
break; 

case KEY.QUEUEOESC: 

/• Test, if queue description already defined V 
if (QueueOef [Number - Ij.DescLine !• -1) 

( 

AddE rror (Li neCount, OOPLICATEJJOESC, Keyword); 
break; 

> 

stmepy (QueueOef [Number - i). Description, Value, 
OESCRIPTION_LENGTH - 1); 

OueueOef[Nucber » l).Oescription[DESCRIPT]ON_LENGTH - 1) « '\Q‘; 

QueueOef (Number - lj.Oescline ■ LineCount; 

break; 

break; 

case KEY_QUEUENAKE: 

/" Test, if queue name already defined */ 
if (QueueOef [Number - 1]. Name line I- *1) 

{ 

AddE rror (li neCount, OOP L I CATE_QUEUENAME , Keyword); 
break; 

) 

GetQueueNaee (QueueOef, Value, LineCount, Number >1); 
break; 

case KEYJUEUEPROC: 

/•Test, if queue processor already defined •/ 
if (QueueOef [Number » l].QueueprocLine 1* -1) 

{ 

AddError( Li neCount, OUPL 1 CATE JUEUE PROD, Keyword); 
break; 

} 

for (i » 0; i < (siieof (QueueProcs) / siieof(PCHAR)); « 

( 

if ( l st Hemp (Value, QueueProcsIi])) 
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{ 

strcpy(QueueBef[Nuttber * lJ.Queueproc, CueueProcs[1 ]); 
QueueDef [Nunber • l].Oueueprocline • LineCount; 
break; 

) 

) 

if (i >■ (si zeof (QututPrecs) / Slzeof(PCKAR))) 

AddErrordi neCount, INVAUOJJUEUEPROC, Value); 
break; 

case KEYJUEUE: 

rc * GetPrinterConnect ions (Value, AQueueDef [Number * l). 

Line Count); 

If (Ire) 

rttum( (PRE$P0NSE_INF0)NULL) ; /* If memory error, return */ 

break; 

case KEYjoWfBRT: 

I* Test, if coamunl cat Ions port already defined "/ 

If (PortOef [Number • l).Lim !• *1) 

{ 

AddErrordi neCount. 0UPLICATE_P0RT0EF, Keyword); 
break; 

) 

GetCocnPcrtOefiniti on (Value, 4Part Be f[ Number - 1], lineCount, 
Keyword); 



break; 

case KEYJIEFAULTPRINTEA: 

If (UsStringNumeric(Value)) I* Test for numeric value *7 

AddErrordi neCount, N8N NUMERIC, Value); 

else 

C 

Number » atol (Value); t* Test value V 

if ( (Umber < 1) 1 1 (Number > KAX_PRJNTERS)) 

AddError(Li neCount, INV OEFAULT PRINTER, Value); 
else 
< 

Responselnfo.DefPrtLire • lineCount; 

Respanselnfo. Befoul tPrinter » Number; 

) 

) 

break; 

cast KEYJJEFAULTQUEUE: 

if (lIsStringNueeric(Value)) /* Test for numeric value V 

AddErrordineCount, KQN NUMERIC, Value); 

else 

{ 

Number - atol (Value); /* Test value V 

If ((Number < 1) II (Number > KAX_QU£UES)) 

AddErrordi neCount, INV_CEFAULT_QUEUE, Value); 
else 
{ 

Responselnfo.DefGueline * LineCount; 
Responselnfo.OefaultQueue « Nunber; 

) 

) 

break; 

case KEYJUJDITIONALPRT: 

GetAddPrinterOrivers(Value, PrinterOese, LineCount); 
break; 

) f* endswltch */ 



) 

) 

Crosscheck (4Ri spans* Info, PrinterOese); 

if (ErrorCount) 

{ 

qsort((PV0I0)ErrorTnb1e, ErrorCount, slzeof(ERROR_STRUCT), SortErrorTable); 
fseek (Stream, 0L, SEEK.SET); 

LineCount ■ 0; 

for (i » 0; i < ErrorCount; !♦♦) 

{ 

while (ErrorT abl e [i ] . Li neKudier > LineCount) 

< 

LineCount**; 

fgets(Buffer, sizeof (Buffer), Stream); 

If (LineCount •* ErrcrTebie[l].l1neNuinber) 

{ 

Buffer [sizeof (Buffer) . 1) - *\G'; 

If (Buffer[j ■ (strlen(Buffer) - 1)] 1 \x8A ’ ) /* Eliminate l/F V 

Buffer[j] - -VQ* ; 

) 

) 

if (strstr(ErrorMsg[ErrorTeblt[f). ErrorNumber), "Ns")) 

{ 

sprl ntf (Error, ErrorMsg(ErrorTabl e(i ) .ErrorNumber) , 

£ rrorT abl e[i), Text, LineCount); 
free (ErrorT abl e[l ] .Text) ; 

) 

else 

Sprl ntf (Error, ErrorKsg[ErrorTobleli J. ErrorNumber], LineCount); 

street (Error, "\n •); 

street (Error, Buffer); 
log(-l. Error); 
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) 

sprintf (Buffer, "Analiting of printer response file completed with %s%d errerts", 
ErrorCount > KAX_ERRORS ? "oore then “ : Ablenn[st 2 eof(blenK) -1], 

Error Count, 

ErrorCount > 1 ? "s" : AblanK[sl 2 eof(blenx) * 1)); 

Log(-l, Buffer); 

) 

else 

log(-l, "Anal i ting of printer response file completed with no errors”); 

InfoMsg(HULL); /* Print info cess ages V 

f close (Strean); 
return (AResponselnfo) ; 

) 



t* Compare routine for sorting the error table V 

f* V 

f* int SortErrorT able (void *, void “); V 

/* •/ 

/• Paraaeter: V 

/* V 

/* void * Pointer to Elettent 1 V 

/" void ■ Pointer to Elecent 2 */ 

/* V 

/• Return: */ 

r */ 

/" result of the comparison */ 

/* V 



int cdecl Sort£rrorTable(void *Errorl, void *Error2) 

{ 

retum( ( (PERR0R_ STRUCT ) E rrorl ) -> L i neNunber - 
( (PERROR - STRUCT ) E rror2) *> L i neNucber) ; 

> 



/• Add error to error table */ 

/* */ 

/* VOID Add£rror(USKORT, USKORT. PCHAR) ; V 

/* V 

/* Parameter: V 

/* V 

/* USKORT Line nucber with error */ 

/* USHORT Error number */ 

/* PCKAR Additional text for error cessage */ 

/* V 

/• Return: «/ 

/* V 

/* none */ 

/• */ 

* *—***/ 

VOID AddError (USKORT LineNunbe-, USHORT ErrorNunber, PCHAR Text) 



{ 

if (ErrorCount < MAX ERRORS) 

( 

Error! able (ErrorCount). H neNunber e Li neNunber; 
ErrcrTabletErrorCountj.ErrorNusher « ErrorNucber; 

if (Text !« Kh:) 

E rrorT abl e [ErrorCount ] .Text - strdup(Text); 
else 

ErrorT able (ErrorCount). Text * NULL; 

} 

if (ErrorCount < (KAX.ERRORS ♦ 1)) 

ErrorCount**; 

) 









/* Get printer pert definition 


V 


/" 




*/ 


f V010 OetPrinterPort (PPRINTEROEF, PCHAR. SHORT, USHORT); 


*/ 


/- 




V 


/* Paraaeter: 




*/ 


/* 




*/ 


/• PPRINTEROEF 


Printer definition structure table 


V 


i* PCKAR 


Paratteter 


*/ 


/* SHORT 


Nucber of printer (6-based) 


V 


/* USKORT 


Line number 


V 


/* 






/* Return: 




•/ 


/* 




*/ 


/* none 




V 


r 




*1 



^AAaAaaaAaAaaaaAAaaaaaa aaa«aaaAAaaaaa*a**ft*AAa*aft aaaaaaaaAAaAaa aaaaaAaAAAA^ 

VOID GetPrinterPort (PPRINTEROEF PrinterOef, PCKAR Value. 

SHORT Nucber. USKORT Li neNunber) 

( 

if (Inert cap (Value, ”LPT“, 3)) /* iPTx? •/ 

( 

if ((Value [3] > ’8* ) 44 (Value [3] <« '9') 44 /• valid IPTx? */ 

((Value(4) ■■ •:') II (Va1ue[4) -« AO'))) 

( 

PrinterOe f (Number). Port (0) - l L'; 

PrinterOef (Number). Port [1) • Value [3) - 'O'; 

PrinterOef [Number). Port Lint ■ LineNuaber; 
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/• Invalid LPTx V 



} 

else 

AddError(li niNunber, INVALID PORT, Value); 

) 

else 

if (! mem i cup (Value, "COM", 3)) f* C0Hx? */ 

( /* valid CQMx? */ 

if ((Val ue(3) > -0-) && (Value [3] < ’4’) && 

( (Val ue(4] »■ •;*) II (Value(4] - *\9’))) 

{ 

Print»rDef[Number].Port[0] * 'C; 

Pri nterOef [Number] .Port (1 ) » Value[3] - '9'; 

Pri nterOef [Number] .Port Li ne - LineNumber; 

) 

else 

Add£rror(LineNutber, INVAUO PORT, Value); /* Invalif COKx */ 

) 

else 

AddError(lineNunber, INVALID PORT, Value); 

) 



/*• 








f* 


Extract printer driver information from printer definition 


V 


/' 






V 


t* BOOL Get Pri nterOri vers (PCHAR, PPRINTERDEF, PPRDESC, USHORT); 


V 


/" 






V 


/* 


Parameter: 




V 


t* 






V 


/* 


PCHAR 


Parameter string 


V 


/* 


PPRI NTEROEF 


Printer definition structure 


V 


/* 


PPRDESC 


Chained list of printer descriptions 


V 


r 


USHORT 


Line number 


V 


/* 






V 


/* 


Return: 




*/ 


r 






-/ 


f* 


none 




V 


/* 

/** 






V 



BOOL Get Pri nterOri vers (PCHAft Value, PPRINTERDEF PrinterDaf, 

PPRDESC PrinterOesc, USHORT LineNumber) 



static 

static 



USHORT PrinterCount • 0; 

PPRDESC PHnterDescPtr; 

CHAR Del imiter[] - - 

CHAR Tecc(6]; 

SHORT re » RSP_N0_ ERROR; 

i nt error; 

USHORT Keyvalue; 

PPRTORVOEF Oriverlnfo; 
PPRTORVDEF DHverlnfoNew; 



/* If first call, find out the number of printer descriptions */ 
if (I PrinterCount) 

for (PrinterDesePtr * PrinterOesc; 

PrinterDescPtr !« (PPRDESC) NULL; 

PrinterDesePtr « PrinterOescPtr->n8Kt) 

PrinterCount**; 

Value • st rt ok (V alue, Deli niter); /• Find first value */ 

while (Value) 

{ 

error • 0; 

if (UsStringNuseric (Value)) /* Test for numeric value */ 

{ 

AddError(LineNuRber, NON_NUHERIC, Value); 
error • J; 

} 

if (1 error) /* Test, if value in range *f 

Keyvalue ■ atoi (Value); /* Convert to integer */ 

if ((Keyvalue <1)11 (Keyvalue > PrinterCount)) 

( 

Add£rror(L?neNuaber, INVJLEYVALUE. Value); /* Keyvalue not in range V 
error • 1; 

) 

) 

if (terror) /* Test, if Keyvalue already defined */ 

{ 

for (Oriverlnfo • PrinterOef->DriverInfo; 

Oriverlnfo !■ (PPRTORVOEF) NULL; 

Oriverlnfo « Dri verlnfoonext) 

{ 

if (Dri verlnf o«>i ndex ■* Keyvalue) 

{ 

ltoa(Key value, Temp, 10); 

AddError(LineNuaber, DUPLICATE JiEYVALUE, Temp); 

error • 1; 

breaK; 

) 

) 

) 

if (1 error) 

{ /• Allocate new structure for driver information */ 

if ((DHverlnfoNew • (PPRTORVOEF )mal 1 cc (si teof (PRTORVOEF)) ) -» 

(PPRTORVOEF)NULL) 
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{ 

Log(-l, “Not enough Denary to analize punter response f11e\n"); 
return (FALSE); 

) 

menset ( (PCKAR) Dri ver] nf oHew, * \8\ si zeof (PRTORVOEF) ) ; 

Ori verInfoNtw->indtx * Keyvalue; /* Set key value •/ 

/* Put structure into chained list */ 
if (Printer0ef->0ri ver Info - (PPRTORVDEF)KULL) 
PrinterOef->DrivirInfo ■ OriverlnfcKew; 
else 
{ 

for (Driverlnfo ■ PrinterOef*>Dri verlnfc; 

OHverlnfo->next !• (PPRTORVDEF)KULL; 

Driverlnfo ■ DriverInfo*>next); 

Dri verlnfo*>tiext ■ OriverlnfoKew; 

) 

PrinterOef“>Orvlnfoline ■ LineKunber; 

) 

Value * strtok (NULL, Del loiter); /* Find next value */ 

) 

return (TRUE); 

) 







•V 


/* Extract additional printer driver infontation fron printer definition 


*/ 


/■ 




V 


/" VOID GetAddPri nterDri vers (PCKAR, PPROESC, USKORT); 


V 


/* 




V 


/* Parameter: 




V 


/* 




V 


/* PCHAR 


Paraneter string 


V 


/• PPROESC 


Chained list of printer descriptions 


*/ 


/» USHORT 


line number 


V 


/* 




•/ 


/* Return; 




•7 


/* 




•/ 


/* none 




*/ 


/* 




V 


/* 




•/ 


/* Author; Gert Ehing ITSC Boca Raton, Florida Oete: 12/12/91 


V 






‘V 


VOID 


GetAddPri nterOrf vers (PCKAR Value, PPROESC PrinterOesc, 


{ 

static USHORT 


USHORT LineNueber) 




PrinterCount » 8; 




PPROESC 


PrinterOescPtr; 




Static CHAR 


Delimiter!) • ■ ,*; 




int 


error; 




USKORT 


Keyvai ue; 




/* If first call. 


find out the number of printer descriptions */ 





if (TPrlnterCcunt) 



for (PrinterOescPtr • PrinterOesc; 

PrinterOescPtr !• (PPROESC)NULL; 

PrinterOescPtr ■ PrlnterDescPtr->next) 

Pri nterCount**; 

Value « strtok (Value, Oeliaiter}; /* Find first value V 

while (Value) 

( 

error * 8; 

if (IlsStringNuneric (Value)) /* Test for numeric value */ 

{ 

AddError(LineNuBber, NON.NUHERIC, Value); 
error « 1; 

) 

if (lerror) /" Test, if value in range •/ 

{ 

Keyvalue > atoi (Value); /* Convert to integer *f 

if ((Keyvalue < 1) il (Keyvalue > PrinterCount)) 

( 

AddError(LineKuisber, INV_KEYVALUE, Value); /* Keyvalue not in range V 
error ■ 1; 

) 

) 

if (I error) 

{ /• Allocate new structure for driver information V 

/* Mark printer description for installation */ 

Get DescByNucsber (PrinterOesc, Keyvalue)-* Inst Flag • TRUE; 

) 

Value • strtok(KULL, Del ini ter); /* Find next value V 

> 

) 



/- 


Get printer naae 




V 


/• 






*/ 


/* 


VOID GetPritttirHe«e(PPRINTERDEF, PCHAR, USHORT); 


V 


/* 






V 


/• 


Parameter: 




V 


/• 






-/ 


/* 


PPRIfiTEROEF 


Printer definition structure 


V 


/* 


PCHAR 


Parameter 


V 


/* 


USHORT 


Line number 


V 
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Nuwber of printer (9«based) 



t* SHOR 

/* 

Z* Return: 
/* 

/* none 

/• 



VOID OetPri nterNeee (PPRINTERCEF PrinterDef. PCKAR Value, 
USHORT LlneMuBber. SHORT Kucber) 

{ 

if (strlen (Value) >0) /‘If printernaee longer than B, 

{ /* truncate it 

Value [8] « ‘\Q'i 

AddErrorflineNuisber, PRTNAME.TRUWATEO, Value); 



) 



V 

V 

V 

V 

V 

V 
'•/ 



V 

V 



strcpy (Pri nt erQef [Kutter] .Wane, Value); 
Pri nterOef [Number) .Has* l i ne - lineXucber; 
) 









/* Get queue nane 




V 


/* 




*/ 


/* VOID GetOueusNaete (PQUEUEOEF, PCHAR. USHORT, SHORT); 


V 


/* 




V 


/* Parameter: 




V 


/* 




V 


/‘ PQUEUEOEF 


Queue definition structure table 


*/ 


/» PCKAR 


Paraeeter 


V 


/* USHORT 


Line nueber 


V 


/* SHORT 


Kunber of printer (9-based) 


V 


/* 




V 


/* Return: 




V 


/* 




V 


f* none 




V 


/* 




*/ 





V0I0 CetOueueNace(POUEUEOEF OueueOef, PCKAR Value. 



USHORT LineNuBber. SHORT Number) 

{ 

USHORT 1 ; 

if (strlen(Value) >0) /‘If queuenaste longer than 6, V 

{ /* truncate it */ 

Value [0] • \0‘ ; 

AddError(LineNumber, QlfEUENAME TRUNCATEO, Value); 

} 

/* Test, of aueuenase already defined */ 
for {i « 0; i < MAX QUEUES; i+*) 

{ 

if (QueueOef(i].NaeeLine I- -1) 

{ 

if (! St rl cop (Value, QueueQef(i).Nase)) 

{ 

AddE rror ( L i neRusbe r , QU£U£KAME_IH_USE. Value); 
return; 

) 

) 

) 

strcpy(OueueCef(Ku«oer].HaEe, Value); 

OueueOef [Kucher). Naceiine « LineHucner; 

) 





/* Test a string for numeric »/ 

/* */ 

r 6801 IsStringNuceric(PCHAR); */ 

/* */ 

/* Paraceter: */ 

/" V 

/* PCKAR String */ 

/* V 

t* Return: •/ 

/• */ 

/* TRUE String contains only nuneric characters V 

/" FALSE String is not nuieric */ 

„ V 

600L I sSt ri ngNuceri c (PCHAR String) 

{ 

for (; ‘String; String**) 
if (!isdi git (‘String)) 
return (FALSE); 



retum(TRUE); 

) 



/* Get printer connections 
/» 

/* BOOL GetPr interconnect ions (PCKAR, PQUEUEOEF, USHORT); 



*/ 

V 

V 



/• V 

/■ Paraceter: */ 
/- v 
/• PCKAR Parameter */ 
/‘ PQUEUEOEF Queue definition structure */ 
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/* USHQRT Line number 

/* 



•/ 

V 



/* Return: 



*/ 



/* 

/* FALSE Not enough memory to allocate printer conn, info 

/* TRUE OK 

/* 





BOOL 


GetPrinterConnect ions (PCHAR Value, POUEUEOEF QueueOef, 


{ 




USHORT LintNueber) 


PPRT_COKN 


PrtConn; 




PPRT~CONN 


PrtConnNew; 




PCHAR 


PrtNrStr; 




PCHAR 


OrvNrStr; 




USHORT 


PrtNr; 




USHORT 


OrvNr; 




CHAR 


Text [28); 


static 


CHAR 


deli*iter[] « " 



7 

7 

7 

7 

7 



/• Separate parameters •/ 

if ((PrtNrStr » strtotc (Value, del loiter) ) ■* NULL) 

{ 

AddError ( L i neKueber , INVALI0_PARM, NUU); 
return (TRUE); 

) 

if ( 1 1 sSt ri ngNuiteri c (PrtNrSt r) ) /* Tost, if printer number is numeric •/ 

{ 

AddError(Li ntNutber, NON_NUMERIC_PRT, PrtNrStr); 
return (TRUE); 

) 

PrtNr • at Oi (PrtNrStr); 

if ((PrtNr < 1) II (PrtNr > MAX PRINTERS)) /- Test for invalid printer number */ 

{ 

AddError (UneNustber, INVAIID_PRT_VALUE, PrtNrStr); 
retum(TRUE); 

) 

if ((OrvNrStr ■ strtox(NULL, delimiter)) NULL) 

BrvNr » -1; 
else 
{ 

if (IIsStringNuceric(DrvNrStr)) /* Test, If driver nucber is nuceric */ 

{ 

AddErrorUineNutber, NON_NUKERIC_ORV, OrvNrStr); 
return (TRUE); 

) 

if ((OrvNr ■ at oi (OrvNrStr)) < i) f* Test for invalid driver number */ 

{ 

AddError (LlneNunber, INVALID_0RV_VAIUE, OrvNrStr); 
return (TRUE); 

) 

} 

! w Test, if connection to printer ol ready cede 7 
for (PrtConn • QueueOef->PrtConn; 

PrtConn !« (PPRT_CONN)NUU; 

PrtConn • PrtConn->next) 

{ 

if (PrtConnoPrlnter »■ PrtNr) 

{ 

sprintf (Text, "Printer%d", PrtNr); 

AddE rror ( L i neNunber, ALREAOY_CONNECTEO, Text); 
return (TRUE); 

) 

) 

/* Allocate new structure */ 

if ((PrtConnNew - (PPRT C0NN)nal 1 oc(si 260 f (PRT CONN))) »» (PPRT C0NN)NUU) 

( 

log(“l, "Not enough memory to analize printer response file\n"); 
retum(FALSE); 

) 

/* Set contents of structure V 
PrtConnNew->next • (PPRT_CONN)NULL; 

PrtConnNew->Printer » PrtNr; 

PrtConnNew->Dri ver ■ OrvNr; 

PrtConnNewoiine • Li neKueber; 



/* Put structure into chained list V 
if (QueueOef*>PrtConn »* (PPRT CONN) NULL) 
( 

if (OrvNr •» -1) 

PrtConnNew->DH ver • 1; 
OueueOef*>PrtConn • PrtConnNew; 

) 

else 

( 

for (PrtConn • QutueDef->PrtConn; 

PrtConnonext !• (PPRT_COKN)NULl; 
PrtConn • PrtConn->next); 
PrtConn->ntxt • PrtConnNew; 

> 
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return (TRUE); 

} 



' * / 

f* Get cctatunl cation ports definitions */ 

r v 

/* VOIO GetCo«aPortOefin?ticn(PCHAR, PPORT OEF, USHORT, PCHAR); V 

r ~ v 

/* Parawter: •/ 

/" ./ 

/* PCHAR Poraneter •/ 

/* PP0RT_0EF Port definition structure */ 

/* USHORT Line minder •/ 

/* PCHAR Keyword */ 

/* V 

/* Return: •/ 

/* V 

/* none •/ 

'* V 

“ . — — — / 



VOIO CetCoiKPortOefimti on (PCHAR Value, PP0RT_D£F PortOef, 

USHORT LineNucber,~PCKAR Keyword) 

static USHORT ValidSaudRates[] « 

{ 

ne. 

159, 

390. 

600, 

1208, 

1688, 

2488, 

3688, 

4600, 

7298 , 

9608, 

19288}; 

static PCHAR ValidStopBitsO - 

{ 

“ 1 *. 

-1.5-, 

-2% 

); 





PCHAR 


BoudRatePtr; 




PCHAR 


PorityPtr; 




PCHAR 


DotaBitsPtr; 




PCHAR 


StapBitsPtr; 




PCHAR 


HandshakePtr; 




USHORT 


BaudRate; 




USHORT 


0 oto 8 its: 




UCKAR 


StepBits; 




USHORT 


i; 


static 


CHAR 


0 elfniter[] ■ 


static 


CHAR 


Default Pori ty[] • "O' 


static 


CHAR 


Default Handshake [] * 


♦define 




Default BaudRate 1286 


♦defi ne 




OefaultDataBits 7 


♦define 




OefaultStopBits *A’ 



BoudRatePtr » ParityPtr • OataBitsPtr « StcpBitsPtr • HendshafcePtr « KULl; 
/* Separate paraseters •/ 

if ((BoudRatePtr • strtok(Volue. Oeliniter)) 1- KULl) 
if ((ParityPtr » strtok(NULl, Oeliniter)) 1» KULl) 
if ((DotaBitsPtr • strtoK(KULL, Oeliniter)) !» HULL) 
if ((StopBItsPtr » strtOK (NULL , Oeliniter)) !- KULL) 

KandshakePtr • strtoic(NULL, Oeliniter); 

/* Checic Baud rate */ 
if (BoudRatePtr) 

( 

St Hp (BoudRatePtr); 
if (* 8 audRotePtr) 

{ 

if (!IsStringKuneric(BaudRatePtr)) 

{ 

AddError(Li neN under, KONNUMERK.BAUQRATE, Keyword); 
return; 

) 

BaudRate » atoi (BoudRatePtr); 
f* test, if doud rate is in range */ 

for (i > 8 ; i < (sizeof(ValidBaudRotes) / si zeof (USHORT)); 144 ) 
if (BaudRate ■■ VolidBoudRotesfi]) 
fare ok; 

if (i >• (si zeof (Val i dBoudRates) / si zeof(USHORT))) 

{ 

Add£rror (L i neKunber, IKVALI0_BAUDRATE, BoudRatePtr); 
return; 

) 

) 

else 

BaudRate * Oe fault BaudRate; 

> 

else 

BaudRate ■ Default BaudRate; /* Set baud rate to default •/ 
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/• Check parity •/ 
if (ParityPtr) 

{ 

it rupr (Stri p (Pari tyPt r) ) ; 
if ("ParityPtr) 

( 

/* Test if parity is a valid value •/ 
if ((strlen(ParltyPtr) I» 1) II 
((•ParityPtr 1- 'N‘ ) && 

(•ParityPtr !» ’O') && 

(•ParityPtr 1» *E’))) 

{ 

AddError(lineNucber, lWVAlIQPAAITY, ParityPtr); 
return; 

} 

) 

else 

ParityPtr » DefaultParity; 

) 

else 

ParityPtr ■ DefaultParity; /• Set parity to default •/ 

/" Cheat Datebits •/ 
if (DataBi tsPtr) 

( 

Stri p (DataBi tsPtr) ; 
if (*0ataBi tsPtr) 

( 

if ( II sStringNtreeric (Oat aBi tsPtr)) 

( 

AddE rror ( L i neNucber, N0KNUMERIC_0ATA91T$* KeyWcrd); 

return; 

} 

OateBits * etoi (DataBi tsPtr); 

/• test, if valid value for data bits •/ 
if ((DataBits < 5) 1 1 (Oatafiits > S}) 

{ 

AddE rror ( L i neNucber, INVALID.DATABITS, DataBi tsPtr); 
return; 

) 



) 

else 

OateBits * OefaultDataBits; 



) 

else 

DataBits • OefaultOataBits; /• Set data bits to default •/ 

/• Cheat Stcpbits •/ 
if (StopBi tsPtr) 

< 

Stri p(StopBi tsPtr); 
if (•StopBitsPtr) 

( 

/* test, if stop bits are in range •/ 

for (i » 0; i < (sizeof(ValidStopBits) / sizeof (PCHAR)) ; i++) 
if (1 strcap (StopBi tsPtr, ValidStopBits(i))) 
break; 

if (i >• (sizeof (ValidStopBits) / si zeof (PCHAR))) 

( 

AddE rror (LineNuaber, IHVAUO_STOPBITS, StopBitsPtr); 
return; 

) 

StopBi ts • (UCKAR)'A’ + (UCHAR) (USHCAT)i ; 

) 

else 

StopBi ts « OefaultStopBits; 



) 

else 

StopBi ts ■ Default St opBits; /* Set baud rate to default */ 

/* Cheat handshake •/ 
if (KandshenePtr) 

( 

Strupr(Strip(HandshaicePtr)) ; 
if (*KandshaxePtr) 

( 

/* Test if Handshake is a va’id value V 
if ((strltn(HandsheicePtr) !■ 1) II 

((•HandshekePtr !* * W ) && 

(•HandshenePtr !* 'H 1 ))) 

{ 

AddError(LineNumber, INVALlOJiANDSKAXE, HandshakePtr); 
return; 

) 

) 

el se 

HandshakePtr • DefaultHandshoke; 



) 

else 

HandshakePtr ■ Oefaul t Handshake; /• Set parity to default •/ 
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PortDef->8audRote * BaudRate; 
PortDef->OataBits ■ OataBits; 
PortDef->Line * lineNunber; 
PortDef->StopBitS * StopBits; 
PortOef->Parity * "ParityPtr; 
PortOef->HandShake - *Handshe*ePtr; 



— — V 

/* Add info nesssege to chain */ 

/* V 

/* VOID Inf oMsg (PCHAR); */ 

/* V 

/* Parameter: */ 

/* «/ 

/* PCHAR Info nessage text, if NULL print info aessages to V 

/* logfile. V 

/* */ 

/* Return: */ 

/* •/ 

/* none */ 

/* */ 

VOID InfoM$g(PCHAR Text) 

{ 

static PINF0,MSG Infoasg * (PINFO MSG) NULL; 

USHORT i ; 

PIKF0_MSG Newlnfo; 

PINF0_MSG InfoasgPtr; 



if (Text - NULL) 

{ 

/* Print info Brassages to logfile V 
if (Infosisg !« (PINFO M$G)NUll) 

{ 

for (InfoiasgPtr - Infotnsg, Newlnfo - (PINFQ_KSG)NULL; 

InfomsgPtr 1« (PINFO_MSG)NULl; 

InfonsgPtr » InfonsgPtr->next) 

( 

if (Newlnfo J- (PINFO_MSG)NULL) 
free ( (PCHAR)NewInfo) ; 

Log(-l, InfonsgPtr->Hessage) ; 

Newlnfo « InfonsgPtr; 

) 

free ((PCHAR) Newlnfo); 

) 

) 

else 

{ 

/* Allocate text for Message */ 

if ((Newlnfo » (PlNF0_MSG)ea1 loc(i - strlen(Text) + 

sizeof([NFD MSG))) !> (PINFO MSGjNULL) 

{ 

Newlnfo- >next ■ (PINF0_MSG)NULL; 
strcpy(NewInfo->Message, Text); 

/* Put structure into chain */ 
if (Infomsg =* (PINFO_MSG)NUU) 

Infotag * Newlnfo; 
else 
{ 

for (InfonsgPtr ■ Infoosg; 

InfonsgPtr->next != (PINFQ_KSG)NUIL; 

InfonsgPtr ■ InfonsgPtronext); 

InfoinsgPtr->next « Newlnfo; 

) 

} 

) 

) 



H.8 C Source for RESPCHK.C 

This module is checking the dependencies between the printers, ports and 
queues. 



/* Cross-checking of the response file info */ 



♦include <stdlib.h> 
♦include <stdio.h> 



iinclude <string.h> 
♦include <«eoory.h> 



♦define INCL.WINSHELLDATA 
♦include <os2.h> 



♦include “rinstprn.h" 
♦include “r_error.h" 

♦define 0E8UG_no 
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USKORT APIENTRY ShePIIni tlni FilestPCHAfl.PCHAR) 



typedef struct 

{ 

PCKAR 

PCKAR 

PCKAR 

} 



InstalledPrlnters; 
Install edQueues; 
UstdPorts; 

INST JNFO, • PINSTJNFO; 



PINSTJNFO Getlnstal 1 Info (VOID); 



/* Cross-checking of the response file info */ 

/• V 

/• BOOL Crosscheck (PRESPONSEJNFO) ; V 

/• V 

/• Pareceter: V 

/• V 

/• PRESPONSEJNFO Response file Inforaation structure ■/ 

/• ' V 

/* Return; */ 

/* V 

/- BOOL V 

/* V 

/•* Author; Qert Ehing Oecesfcer 1991 ITSC Boca Raton, Florida */ 





V0I0 Crosscheck (PRESPONSE INFO Responselnfo, PPRDESC PrinterOesc) 

{ 

SHORT i,j; 

CHAR Messoge[B0] ; 

PPRINTEROEF PrtOef • ResponseInfo->PrinterOef; 

POUEUEDEF OueueOef ■ Responselnfo*>0ueue08f; 





BOOL 


Error; 




SHORT 


ConnCount ; 




SHORT 


HsgNr; 




PPRT CONN 


PrtConn; 




PPRTORVOEF DrvOef; 




PPROESC 


DescPtr; 


static 


CHAR 


Msgl () ■ "Printer%d/PrlnterPort%d"| 


static 


CHAR 


Msg2() ■ "Printer%d"; 


static 


CHAR 


Ksg3(j • “PrinterPortNd"; 


static 


CHAR 


Msg4() • -OueueW; 




SHORT 


PrinterNusber; 




PINSTJNFO 


Install Info; 




PCKAR 


Test; 



/* Get inforaation about previously Installed prlnters/aueues/ports */ 

Install Info • Get Install Info (); 

/* Check, if printer info missing */ 
for (I ■ 6; i < MAX PRINTERS; !♦♦) 

( 

Error » FALSE; 

/* Any inforaation for that printer defined? */ 

If ((PrtOef(i] .Orvlnfoline !• NOT.DEFINEO) II 
(PrtOef(i].Portline !■ NOTJJEFINED) II 
(PrtOef (l).Nenelfne l» NofoEFINED) II 
(PrtOef(l).DescLine !• NOT DEFINED)) 

{ 

/* Both printer and printerport inforaation aiss*ng? */ 
if ((PrtDef(l). Orvlnfoline NOTJJEFJNEO) && 

(PrtOef ( I ). Portline •• NOT DEFINED)) 

{ 

MsgNr • PRINTER^DEF_HISSING; 
sprlntf(Kessage, Msgl, 1 + 1, i + 1); 

Error « TRUE; 

) 

else 

/• Only printer inforaation aissing? */ 
if (PrtOef (l ). Orvlnfoline NOT DEFINED) 

{ 

HsgNr ■ PRINTER_0EF_MISSING; 
sprintf (Message, KsgE, 1*1); 

Error • TRUE; 

) 

else 

/• Only printerport inforaation aissing? */ 
if (PrtOef [IJ.Portline - NOT DEFINED) 

{ 

MsgNr • PRI NT E R_DE F J4I SS I NG ; 
sprintf (Message, Msg3, i ♦ 1); 

Error • TRUE; 

) 

if (1 Error) 

{ 

if (PrtOef(i).NaaeLine <• NOT DEFINED) 

{ 

/* Generate printer naae V 

Generat eNatse (PrtOef [iJ.Nane, PrtOef(i ] .Driverlnfo->index, 

(SHORT ) PrtOef [i ) .Port (l ) , PrinterDasc) ; 

PrtOef (i). Naae line • GENERATED; f* Mark line as generated V 

) 

if (PrtOef [l].Oescline <- NOT DEFINED) 

{ 

/* Generate printer description V 
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GenerateOesc (PrtDef [ i ) .Oescri pti on, PrtDef [i] .Dri verInfo->index, 
PrtDef (i ). Port, PrinterQesc) ; 

PrtDef (i). Oescli ne • GENERATED; /* Mark line as generated */ 

} 



/• Test, if p-intematee al reedy defined in 0S2.INI •/ 
if ({Test - Instal Unfo->InstalledPrinters) ! * NULL) 
for (; *Test !* *\0‘; Test ♦* (strl en(Test) ♦ 1)3 
{ 

if (!stri emptiest, PrtDef(iJ.Nane)) 

{ 

Error » TRUE; 

st rcpy (Message, PrtOef[i].Nere); 
if (PrtDef(i).Naceline ■= GENERATED) 

MsgNr- « GENPRT_fOUND_IN_INI; 
else 

MsgNr » PRT_FOUND_IN_INI; 
breaK; 

) 

) 

) 



/* Test, if printerport already defined in OS2.INI •/ 
if (f Error) 

{ 

if ((Test * Instal Unfo->UsedPorts) 1* NULL) 

{ 

sprintf (Message, '‘ls%d\n", 

PrtOef [i]. Port [fi] «■ *1' ? "IPT" : "COM", 
(SPORT)PrtOef [i J.Port (1)) ; 
for (; “Test !* AD’; Test (strlen(Test) ♦ 1)) 
( 

if (Istri cco (Test, PrtOef[i].Nace)) 

{ 

Error * TRUE; 

MsgNr * PORT_FOUND_IN_INI; 
breaK; 

) 

) 

) 

) 



) 



if (Error) J* If an error detected, generate cessage */ 

( 

if (PrtDef [i ). Drvlnfoline > NOT_DEFINEO) 

AddError(PrtOef [i ] .Drvlnfoline, MsgNr, Message); 
if (PrtDef[i].Portline > NOT JEWED) 

AddError(PrtOef(i)-Poruine. MsgNr, Message); 
if (PrtDef [iMeceilne > GENERATED) 

Add£rror(PrtOef[i).Naneline, MsgNr, Message); 
if (PrtDefliJ.Oescline > GENERATED) 

AddError(PrtDef (i ) .Oescli ne, MsgNr, Message); 

/* Deactivate printer definition V 

PrtOef[i). Drvlnfoline * PrtOef[i].Portline * PrtOef [i Madeline * 
PrtDef[i].Oescline * IGNORED; 



) 



) 



/* ChecK for printer nai»s end printer ports "/ 
for (i » 1; i < MAX PRINTERS; l**) 

( 

if (PrtDefli).NaraeLine <* NOTJEFINED) 
continue; 

for (j - D; j < i; )♦♦) 

{ 

Error « FALSE; 

if (PrtDef lj Maneline <• NOMJEFINED) 
continue; 



/• ChecK for printer name "/ 

if (Istri ccp(PrtDef(i 3-Nace, PrtDef[j] .None)) 

( 

Error « TRUE; 

if (PrtDef[i Meraeline *• GENERATED) 

MsgNr * GENERATJWMEJNJSE; 
else 

MsgNr * PRTNAM£_IN_USE; 

Sprintf (Message, "*d %s already used by Printertd", i ♦ 1, 
PrtDef(i) .Nace, j + 1); 

) 



if (Error) 

{ 

if (PrtOef(i). Drvlnfoline > NOTJEFINEO) 

AddError(PrtDef[i).OrvInfoline, MsgNr, Message); 
if (PrtOef (i ] .Port line > NOMJEFINED) 

AddError(PrtDef(i J.Pomine, MsgNr, Message); 
if (PrtOef(i). Nameline > GENERATED) 

AddError(PrtDef [i Madeline, MsgNr, Message); 
if (PrtOef(i).Descline > GENERATED) 

AddError(PrtDef(i ). Oescli ne, MsgNr, Kessage); 

/* Deactivate printer definition */ 

PrtOef (i], Drvlnfoline • PrtDef [i J.PortLine • PrtDef (i).Naceline • 
PrtDef [i J.DescLine • ICKOREO; 

continue; 

) 
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} 



I* ChecK for printer port */ 

if (PORT2US(PrtDef[i].Port) - P0RT2US(PrtDef(j).Port)) 

( 

sprint f (Message , "%s%d already used by PrinterM*, 

(PrtOeffi). Port (0) .. ? "IPT" : “COM'-). 

(USKORT) (UCHAR)PrtCef (5 J.Port [1], j 4 1 ); 
if (PrtOeffi J.OrvInfoline > NOT_DEFINED) 

AddETor(PrtOef[i].OrvInfoLine, PORT_IN_USE, Message); 
if (PrtOef[i). Port Line > NQT_DEFINED) 

AddError(PrtOef[?].PortLine, P0RT_IN USE, Message); 
if (PrtDef [il.Naraellne > NOTJEFINED) 

AddError(PrtOeffi ). None Line, PORT_IN_uSt, Message); 
if (PrtOeffi). Descline > GENERATED) " 

AddErrorfPrtDeffi }. Descline. PORTINJJSE, Message); 

/* Deactivate printer definition */ 

PrtOeffi). DrvInfoLine * PrtOeffi J.Portline * PrtOeffi J.Neoeilne ■ 
PrtOeffi). Descline * IGNORED; 



) 



) 



/* ChecK the queues V 

for (i ■ 0; 1 < MAX QUEUES; i++) 

{ 

/* Any information for that queue defined? */ 
if ((QueueOeffi ). PrtConn !* (PPRT_CONN)NUU) II 
(QueueOeffi ] .Naceiine :■ NOT OEFINED) li 
(QueueOeffi) .Queueprociine :* NOT_DEFINED) II 
(QueueDeffi ) .Descline !* NOT DEFINED)) 

( 

/" Printer connection missing? */ 
if (QueueDeffi ).PrtConn ** (PPRT CONK) NULL) 

{ 

Sprint f (Message, M$g4, i + 1); 

MsgNr ■ QUEUE_DEF_MISSING; 
if (QueueOeffi J.Nacteline <« N0T_DEF1NED) 

Add£rror(QueueDef fi ). Newline, QUEUE_DEF_MISSING, Message); 
if (QueueDeffi ]. Queueprociine <* NOTDEFINED) 

AddError(QueueDeffi). Queueprociine, QUEUE_DEF_MISSING, Message) 
if (QueueDeffi). DescLine <« N0T_0EFINE0) 

AddError (QueueDeffi). Descline, QUEUE_D£F_MISSING, Message); 
QueueDeffi J.NameLine - QueueDeffi ] .Queueprociine * 

QueueDeffi) .Descline - IGNORED; 

continue; 

) 



/* ChecK printer connections and test if plotter driver is used */ 
/• Initialize queue driver index */ 

QueueDeffi ).QueueDriverlnoex * N0T_DEFINED; 

/ * Look thru the printer connection chain V 
for (PrtConn * QueueDeffi ) .PrtConn, ConnCount s 0; 

PrtConn !* (PPRT_CONN)NUll; 

PrtConn * PrtConn->next) 

( 

/* Look for printer definition */ 

if (PrtDef[PrtConn->Printer - lJ.Nameline <* NOT OEFINEO) 

{ 

sprintf (Message, "\a to PrinterNd", i ♦ 1, ' s rtConn->Printer); 
AddError(PrtConn->Line, PR1 NTEft_NOT_DEf INEO, Message); 
PrtConn. >iine * IGNORED; 
continue; 

) 



/* Look for driver information */ 

DrvDef * PrtDef [PrtConn->Printer - 1] .Dri verlnfo; 
if ((j • PrtConnoDriver) «■ NOT DEFINED) 

{ 

if (QueueDeffi ].QueueDriverIndex - NOT DEFINED) 

J - l; 

) 

else 

for ()♦♦; DrvDef !* (PPRTORVDEF)NUll; DrvDef - DrvDefonext) 

{ 

j-; 

if (j ” 1) 

breex; 

) 

if (j ■■ 1) 

( 

QueueDeffi].QueueDri verlndex * DrvOef*>index; 

PrinterNumber « PrtConn. sprinter; 

) 

else 

if (QueueDeffi J.QueueDri verlndex «« NOT DEFINED) 

( 

Print erNuntber « PrtConn-sPrinter; 

QueueOeffi J.QueueDri verlndex ■ 

PrtDef (PrtConn->Pri nter . l].DriverInfo->1ndex; 

) 

ConnCount ++ ; 

) 

if (I ConnCount) 

( 

sprintf (Message, "%d". i ♦ 1); 
if (QueueDeffi l.Naceline > N0T_0EFINE0) 

AddError (QueueOef [i ) .Naneiine, no_Vaiid_connection, Message); 
if (QueueDeffi). Queueprociine > NOT_OEFINED) 
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AddError (OueueDef [i].Queueprocline, NOJfAl ^CONNECTION, Message) j 
if (OueueDef [ij.Desciine > GENERATED) 

AddError[QueueDef(i].Oescline, NQ_VAtIO_CQNNECTIOK, Message); 
QueueOef(i).Naceline 1 OueueDef (i ) .Queueprociine * 

QueueOef [i ] .Descline > IGNORED; 

continue; 

) 

else 

( 

/* Generate queue none if not defined */ 
if (QueueOef [i Madeline " NOT DEFINED) 

{ 

GenerateNftae(OueueDef fi ] .Name, 

0 ue ue D e f [ i ] . Queue Dri verl n dex , 

(SHORT)PrtDef[PrinterNuaajer - 1 ] .Port [1 ] * 

Print erOesc) ; 

OueueDefli). Name line « GENERATED; 

) 

/* Generate queue description if not defined •/ 
if (Queue0ef[i).0esci5ne ** NOT DEFINED) 

{ 

GenereteDesc(QueueOef [i ] .Oescripti on, 

QueueOef [i ] .QueueDri werlndex, 

PrtOef[PrinterNiraber - lJ.Port, 

PrinterDesc); 

QueueOef (i). Descline « GENERATED; 

} 

/* Generate Queue processor name if not defined */ 
if (OueueDef(i).Queueprocline == NOT DEFINED) 

{ 

DescPtr « Get0esc8yNuniber(PrinterDesc ( QueueOef[i J. QueueDri verlndex); 
if (!strici«p(DescPtr*>drvname, "PLOTTERS. DRV’)) 
strcpy(QueueQef(i ]. Oueueproc, "PMPLOT"); 
else 

St rcpy ( QueueOe f ( i ) . Oueueproc , “ PMPRI N! " ) ; 

QueueOef [i].Oueueprociine = GENERATED; 

) 



) 

) 

/• Check for Queue names *t 
fO" (i » 1; i < MAX QUEUES; i+*) 

( 

if (QueueOef (il.NcueLine <- NOT_DEFINED) 
continue; 

for (j ■ 0; j < i; j++) 

{ 

if (OueueDef [jj.Naneline <« NOT_OEFINED) 
continue; 

if (!stricmp(QueueQef[i].Narce, QueueOef [j] .Name)) 

{ 

if (QueueDef(i).Naaeline ** GENERATED) 

MsgNr * G£WQU£UE_NAM£_1N_USE; 
else 

MsgNr . QUEUE_NAME_IN_USE; 

sprintf (Message, "Ac As already used by QueueAd", i ♦ I, 
OueueDef (i). Name, j + 1); 

/* Deactivate Queue definition */ 
if (OueueDef [iJ.Oesctine > GENERATED) 

Add£rror(QueueQef[i].Oescline, MsgNr, Message); 
if (QueueOef (i).Nemeline > GENERATED) 

AddError(GueueDef[i J.NameLine, MsgNr, Message); 
if (OueueDef [i J.Queueprocline > GENERATED) 

AddError(QueueDef[i ). Queueprociine, MsgNr, Message); 
QueueOef [i], Descline » QueueOef [i].NatieLine • 

QueueOef [i). Oueueproc line > IGNORED; 

for (PrtConn ■ QutueDef[i].PrtConn; 

PrtConn !• (PPRT_CCNN)NULt; 

PrtConn • PrtCcnn*>next) 
if (PrtConn-Hine > KDT DEFINEO) 

{ 

AddError(PrtConn«>Line, MsgNr, Message); 

PrtConn«>Une ■ IGNORED; 

) 

) 

) 

) 

/" Check, if Queuenane already defined in OS?. INI */ 
for (i • 1; \ < MAX QUEUES; !♦♦) 

( 

if (OueueDef [i].Naceline <« N0T_DEFINE0) 
continue; 

if ((Test « Instal 1 Info->lnstal 1 edQueues ) 1« NULL) 
for (; "Test 1« '\0'; Test (strlen(Test) ♦ 1)) 

{ 

if (IstricnpHest, QueueOef (i). Name)) 
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{ 

strcpy (Message, QueueDef (i J .Wane) ; 
if ( QueueDef [i ] .Name Line ** GENERATED) 

MsgNr « CENOU£_FOUNO_IN_INI; 
else 

MsgNr * QUE_FOUNDjN_lNl; 

/" Deactivate queue definition */ 
if (QueueDef [i].Oescline > GENERATED) 

AddError [QueueDef [i ] .Oesciine, MsgNr, Message); 
if (OueueDef [i J.Neneline > GENERATED) 

AddError(OueueDef[i J.Naneiine, MsgNr, Message); 
if (OueueDef[i].QueueprocLine > GENERATED) 

AddError(QueueOef(i j.Queueprociine, MsgNr, Message); 
QueueDef(i].DescLine * OueueDef li Madeline = 

QueueDef(i).Queueprociine * IGNORED; 

for (PrtConn = QueueDef [i ]. PrtConn; 

PrtConn !« (PPRTCONN)NUU; 

PrtConn * PrtConn->next) 
if (PrtConn->tine > NOT DEFINED) 

{ 

AddError (PrtConn*> Line, MsgNr, Message); 

PrtConn->Line * IGNORED; 

) 

break; 

> 

) 

) 

I* Check for default printer/plotter */ 
if (ResponselnfooOefPrtiine !* NOT DEFINED) 

{ 

if ((i • PrtDeflRe5ponselnfe->0efaultPrinter - 1] .Neneline) <« NOT DEFINED) 

{ 

sprintf (Message, "Pnnter%d", ResponseInfo->OefaultPrinter) ; 
AddError(ResponseInfo'>DefPrtline, 

(i •• N0T_DEFINED ? DEFAULT_NOTJEF ; DEFAULT ERROR), 

Message); 

ResponselnfooOefPrtiine * IGNORED; 

) 

) 

if (ResponseInfo->DefQueLine !* NOT DEFINEO) 

{ • 

if ((i » OueueDef [ResponseInfo*>OefaultQueue * l].NameLine) <« NOT DEFINED) 

{ 

sprintf (Message, ■'Queue^^". ResconseInfo->OefaultQueue); 

AddError (Responselnfo*>DefQuel i ne, 

(i «* N0T_0£FINED ? DEFAUlT_NOT_DEF : DEFAULTERROR) . 

Message) ; 

ResponseInfo*>OefQueLine * IGNORED; 

) 

) 

> 





/* Generate printer/queue name */ 

r V 

r VOID GenerateNate(PCHAR, SHORT, SHORT, PPRDESC); */ 

/* V 

/* Paraceter: */ 

/* V 

f* PCHAR Printer none (return) »/ 

/* SHORT Index in printer driver list V 

/* SHORT NurPer of printer port V 

/* PPRDESC Printer description chained list *7 

/* */ 

/* Return: V 

/* V 

/• none */ 

/* */ 

/****•• ******* / 



VOID GenemeNaoe (PCHAR Nane, SHORT Print erlndex, 

SHORT PortNusoer, PPRDESC PrinterDesc) 

( 

Static TRANS NAF£S TrensNanes[] » 

( 

"LASERJET*, "LASER", 

"IBK52B12". "I8MS201 ", 

"SMGXPJET " , "PAINT", 

"PLOTTERS’, "PLOTTER", 

"PMPLOTPD", "PMPIOT", 

); 

USHORT i ; 

PPRDESC PrtOesc; 

CHAR Tecp[?0] ; 

PCHAR TenpPtr; 

PrtDesc ■ Get De sc By N under (PrinterDesc, Printerlndex); /* Get description */ 

strcpy(Tenp, PrtOesc->drvnaise) ; 

if ((TecpPtr ■ strchr(Tecp, .•)) !• NULL) 

MecpPtr ■ ’\0’ ; 

for (i • 6, TecpPtr • Tenp; i < (si zeof (TransNaces) / sizeof (TRANS NAMES)); <♦♦) 

( 

if (lstricKtp(TransNanes(i].Dnverhane, Temp)) 
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{ 

TeapPtr * TransNaoes(i).PrinterPrefix; 
breax; 

) 

} 

sprintf (Nace, “*s%d", TecpPtr, PortNurher); 

} 



/ * 

/* Generate printer/queue description *{ 
/* */ 
/* VOID Generat eOesc (PCHAR, SHORT, PCHAfl, PPRDESC); */ 
/- V 
/* Parameter; */ 

r v 

/* PCHAR Printer nane (return) V 
/“ SHORT Index in printer driver list */ 
/" PCHAR Printer port definition •/ 
/* PPRDESC Printer description chained list •/ 
/• V 

/* Return: •/ 

r V 
/* none •/ 
/* V 
/** * * / 



VOID Generat eOesc (PCHAR Desc, SHORT Printerlndex, 

PCHAR Port, PPRDESC PrinterDesc) 

{ 

PPRDESC PrtDesc; 

PrtOesc * GetBescByNum£>er(PrinterDe$c, Printerlndex); /* Get description */ 
stmcpy(Qesc, PrtDesc->desc, DESCRIPTION J.ENGTH) ; 

Oesc(DESCRIPTION_LENGTH • 1] • *\0*; 

Strip(Desc) ; 

if (strlen(Oesc) < (DESCRIPTION LENGTH - 8)) 

{ 

spri nt f (&Desc[$t rl en(Oesc)] , " On %s%d“. 

(Port [6) “ L* ? "LPT" : "COM”) , 

(SHORT) Port ,'!]){ 

} 

) 



/* * V 

/* Get info about installed printers/queues/ports "/ 

r V 

/* PINST INFO Getlnstal 1 Info(VOIO); */ 

/* " -/ 

/* Pareneter: »/ 

r *f 

/* none */ 

/* */ 

/* Return; */ 

/* •/ 

/* PINST^IHFO Structure with info •/ 

/. “ «/ 
* — * * / 



PINST INFO Getlnstal 1 Info(VOID) 

( 

Static INST INFO Instlnfo * 

( 

NOIL, 

NOLL, 

NOLL 

}; 

static CHAR pn_spooler_printer(] ■ "PM_SP00LER_PRINTER"; 

static CHAR pm_spooler_queue[] * M PM_SPOOIEA_OUEUE“: 

LONG Len; 

SHORT Port len; 

PCHAR Test; 

CHAR Buffer^); 

PCHAR Port ; 

PCHAR OsedPortPtr; 

OSHORT rc; 

static CHAR Oelioitern • 



/* Ouery installed printers V 
#if defined(DEBuG) 

tog{- 1 , "\nbefore ShePI Ini t Ini Fi I e\n‘) ; 

#endi f 

rc*ShePIInitIniFi1es(-C:\\OS2\\OSZ.INr,“C:\\OS2V\OS2SYS.INI-); 

#if defined(DEBUG) 

Log(- 1 , -after ShePIIni tlni Fi 1 e\n“) ; 

#endi f 

len»64080; 

if ((Instlnfo. Install edPrinters « Ball oc( (SHORT) Len)) !■ NOLL) 

{ 

#if defined (OEBOC) 

Log(*l .“before PrfQueryProfi 1eString\n“); 

eendl f 

PrfOueryProfiloString(HlNI_USER,po_spooler_printer, NOLL, NULL, 
Instlnfo. Inst al 1 edPrinters, Len) ; 

fif defined(DEBUG) 
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Log (*1 ("after PrfQueryProfi1eString\r“) ; 

lendi f 

/* Test the used ports •/ 

for (Test * Instlnfo.Instal ledPrinters, PortLen * 2; 

•Test I* \0'; 

Test += (strlen(Test) ♦ 1)) 

{ 

PrfQueryProf i 1 eString (HINIJJSER, pn_ spooler printer. Test, 

- “^Buffer, aONCjsizeof (Buffer)); 
if ((Port * strtoic (Buffer, Delimiter)) !« NULL) 

PortLen ♦* (st Hen (Port) ♦ 1); 

) 

/* Create the string for used ports •/ 
if ((Instlnfo.usedPorts * oeiloc (Port ten)) !* null) 

{ 

for (Test = Instlnfo.Instal ledPrinters, 

UsedPortPtr » Instlnfo.usedPorts; 

•Test 1- '\8‘ ; 

Test +* (strlen(Test) ♦ 1)) 

{ 

PrfOueryProf i 1 eString (HI NI_USER, pm_spooler_printer, Test, 
" ”, Buffer, UONC)sizeof (Buffer)) ; 
if ((Port * strtOK (Buffer, Oeliniter)) ! = NULL) 

{ 

St rcpy (UsedPortPtr, Port); 

UsedPortPtr ** (strlen(Port) * 1); 

) 

•UsedPortPtr « ’\fl' ; 

) 

) 

} 



/• Query installed aueues */ 

if ((Instlnfo.Instal iedQueues « mall oc( (SHORT) ten)) !* NULL) 

( 



PrfQueryProfi leString(HINI_uSER, pn_spool enqueue, NULL, NULL, 
Instlnfo.Instal IedQueues, ten); 



) 



retum(&InstJnfo); 

) 



H.9 C Source for LOG.C 

This module contains the routine to create and write a log file. 

•include <stdio.h> 

•incluoe <stdlib.h> 

•include <string.h> 

•include <os2.h> 

•include "rinstprn.n* 



static PCHAR LogFilename * NULL; 

static CHAR con[] * "C0«‘ ; 

/**• * ******** * - —***•* / 

/* IOC routine */ 

/• •/ 

/• void Log(int, char »); •/ 

/• •/ 

/* Parameter: ■/ 

/• •/ 

/• int Error number •/ 

/• Char • */ 

/• •/ 

/• Return: */ 

/• -/ 

/* none •/ 

/• •/ 

r -/ 

/* Author: Cert Ehing ITSC Boca Raton, Florida Bate: 11/21/91 V 

/ —— — — — — •«/ 

void Log(int Errornr, char •Errornsg) 

{ 

static CHAR Default LogFi lenaoeQ * DEFAULT LOGFUENAME; 

SHORT Error * TRUE; 

FILE *LogStrean; 



while (Error) 

( 

if (logFi lenaoe ** NULL) 

SetLogFi 1 enane(Defaul tlcgFi 1 enase) ; 

if ((LogStrean * fopen(LogFil enact*, "a")) ■■ NULL) 

( 

printf (“Cannot open Logfile %s,", LogFi lenene); 
if (logFilenane -« Default LogFi 1 enane) 

LogFi 1 enacts * Con; 
else 
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Set LogFi 1 enanefOefoultlogFl 1 enwte) ; 



printf (" using %s for LOG output\n", LogFilennna); 

) 

else 

Error - FALSE; 

} 

if (Erromr !» *1) 

f pr i nt f ( LogSt re an , ■RMINSW4.4X: Erromr); 

fprlntf(logStreaa, '%s\n“, Erroresg); 

fclose(Log$trea»); 

} 



/* Set logfile nans */ 
/* V 
/• void SettogFilenane(PCHAR); «/ 
/• V 
/* Parameter; */ 
/• V 
/• PCHAR mm* of Logfile •/ 
/* •/ 
/* Return; */ 
/• •/ 
/* none */ 
/- V 



VOID Set LogFUename (PCKAR Filename) 

{ 

LogFi lenaae * Filenaste; 

if (stri cnp (Filename, Con)) 
uni in* (Filename); 

} 



H.10 C Source for RINSTMSC.C 

This module contains two routines to find information from the printer list and 
description files. 



/• Miscellaneous functions for reeote printer installation V 

•include <stdlib.h> 

•include <stdio.h> 

•include <string.h> 



•include <os2.h> 
♦include "rinstpm.h" 



.......................O../ 

/• Get the n th printer description structure fron chained list •/ 

/- V 

r PPROESC GetQescByKueber(PPROESC, USHORT); V 

/• V 

/• Parameter: */ 

/* V 

/" PPROESC Printer description chained list */ 

/• USHORT N under of entry V 

/• V 

/* Return; */ 

/* V 

PPROESC Printer description structure •/ 

/* */ 

/• Author: 6ert Ehing Decanter 1991 ITSC Boca Raton, Florida •/ 



PPROESC GetOescByHu&berfPPROESC OescPtr, USHORT Index) 

{ 

for (; (Index > 1) U (OescPtr !• (PPROESC) KUL L) S 
OescPtr » De$cPtr->next, Index—); 

return (OescPtr); 

) 



/* Gat the driver struct for a specific driver name 


*7 


/• 




V 


/* PPRORV GetOriverBy Name (PPRORV, PCKAR) ; 


V 


/* 




V 


/* Parameter; 




*/ 


r 




*/ 


/* PPRORV 


Printer driver chained list 


V 


/• PCKAR 


Name of printer driver 


V 


/* 




V 


/* Return; 




V 


/* 




V 


/* PPRORV 


Printer driver structure 


V 


r 




*/ 



** •**•*•*••**«*«• •n*n*« *••**«** *** *••«***«*********** n* » ****** ***««*y 
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PPftOW GetDriver0yNase(PPRORV DriverPtr, PCHAft N«e) 



( 

for (i Ori verPtr !> (PPRORV)Wlll; DriverPtr ■ DrlverPtronsxt) 
if (! stri ccp (Ori vsrPtr*>drvnaae« Nate)) 
break; 

return (OriverPtr); 

) 
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Appendix I. The Create Environment Variable Program Description 



1.1 How to Use CRENVVAR.EXE 

This program prompts for environment variables. It lets the user define the name 
of the variable and type the prompt string, which will be shown when the 
program requests user input. The program requires input and will repeat the 
same prompt, until the user enters any data. The name of the variable and the 
entered data are composed together to form a valid OS/2 "SET"-statement which 
is stored in a CMD procedure called ENV_VARS.CMD. The program deletes this 
file upon program entry. So if the program crashes or receives invalid data, the 
file ENV_VARS.CMD does not exist. By executing the ENV_VARS.CMD after 
CRENVVAR.EXE has finished, the environment variable becomes part of the 
current OS/2 environment. 

Two parameters are valid for CRENVVAR. Both parameters are required and 
used in conjunction. The program always searches for a pair, thereby 
interpreting the command line input from left to right. The two parameters don't 
need to be in a specific order. A request is only put out if both parameters are 
present. 

No blanks are allowed between parameter and data and parameter and 
double-quoted string data (within a string blanks are allowed). Parameters are 
separated by one or more blanks. 

More than one variable can be set by one program execution. After the first pair 
has been interpreted and executed, the program continues with the next set (if 
available) thereby moving from left to right until all parameters are processed. 

Issuing CRENWAR ? outputs a brief explanation of the function and its usage. 
(See the program list below for its content). 

The two parameters are: 

/V: With this parameter the user defines the name of the new or 

replacable environment variable. Any name valid as environment 
variable can be used. If the name already exists, its value will be 
replaced. 

IP: This parameter defines the content of the prompt string. This is the 

string the user will see, when being asked to enter the data for a 
specific variable. If the string contains blanks as word separator, the 
string must be embedded by '"'(double quotes). No colon is needed at 
the end of the string. It is automatically added by the program. 



1.2 Samples with CRENVVAR.EXE 

The first example shows the prompting for one variable. The /v: and / p: 
parameters could be in any order. 

The program call: 
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CRENVVAR /P: "PI ease enter your workstation name" /V:WSNAME 
or 

CRENVVAR /vsWSNAME /p:"Please enter your workstation name" 

would both result in the following execution: 

(MSNAME) Please enter your workstation name: 

(an assumed input from the user could be aywps) 

which results in creation of ENV_VARS.CMD file with the following content: 
SET WSNAME=MYWPS 



The following example issues two prompts for two variables: 
Program call: 

CRENVVAR /V:WSN /P:"WS Name" v:WSA /P:"WS address" 



1.3 Make File, DEF File and Source Code for CRENVVAR.EXE 

The following section shows all information needed to create the environment 
variable prompter program. 

1.3.1 Make File for CRENVVAR C Routine 

Compiler control file used when compiling and link editing the CRENVVAR.EXE, 
the source for which is listed later. 

crenvvar.exe: crenwar. obj crenwar. def 

HnK crenwar /A:16 p crenwar, crenwar, I Hbce*os2 /NOd /HAP .crenwar. def; 

crenvvar.obj: crenwar. c 

d /c /Dd /Zi /Zp /Alfu /W3 /02s /Gc crenwar.c 



1.3.2 CRENVVAR.DEF Define File 

NAM £ CRENWAR WINDGWCOMPAT 

DESCRIPTION ’Create Environment Variables’ 

STUB ’OSZSTUB.EXE* 

DATA MULTIPLE 

STACKS! ZE 4992 
KEAPSIZE 4992 

PRQTMGDE 



1.3.3 C Source for CRENWAR.C 

This module is the main routine for the create environment variables program. 



♦include <stdlib.h> 
♦include <stdio.h> 
♦include <strlng.h> 
♦include <os2.h> 



/* prototypes and •/ 

/• global variables »/ 

/■t***«*«**M***««*«»«*»**«M**MM»M»»»M»**»t*M**t*t»«»*«*»*****»*M«*^ 



SHORT cdecl reqputenv(PCHAR.PCHAR) ; 

Static CHAR Buffer (1980]; 

static CHAR Env Vers[] « "ENV VARS. CKO'; 

FILE -nyfile; 
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/* V 
/• Start of win program V 
/• V 

S««ft*ft««»***ftft*«ft***ft«««*«**«***»#*»**«»*it*»«****rt*ft**«ft*M**«*»**ft»***«*«*«/ 



void cdacl cainfargc, argv) 



{ 


int 

char 


argc; 

*orgv(); 


/* local variables 


static 


CHAR 


Kwdl (] • VV: 1 


static 


CHAR 


Kwd2[) • */P:' 




PCKAR 


EnvVar; 




PCKAR 


ProsptStrl ng; 




int 


i; 



******* ****** ******* f 

V 



«*****»«• *«»*»**« ft************ «»*#*»#»#**»#****• m*mf 

/* description of prcgran V 

^••M*««****M****«ft*********«**iift***«****«tt«*****fi*«**************ii**w**«***y 

If {argc > 1) { 

If ( 1 strcsp (argv [1]. ■?“)) 

{ prl ntf ( 

• Crtatt Envircncent Variabl*s\n“ 

- \ n - 

■\n" 



"\n" 

/* 



Syntox:\n* 



CRENWAR /VsEnvVarlcbleNeeie /P:"ProBptStHng"\n" 



-\n-)i 

printf{ 



"\n") i 
pH ntf ( 



-(/Vsenweri cbl tnace]- 
-i/P:\-PronptStHng\"]‘ 




EnvVarleb1«Kac» 

ProcptStrlng 



Mace of envlromwnt variable to be createdXn" 
Promt string layout \n' 



This program always expects o pair { /v: /p:\n M 
" in any order. It promts as soon, os a /v: and /p: \n" 

" are detected. The result is stored in %s\n" 

■ If this file does not exist, nothing was retrieved.\n" 

"\n*,Env_Vars); 

printff 

"\n- 

" ITSC Boca Raton, florida\n"); 



exit(O); 

) 

) 

if (argc ■■ 1 ) {return;} /• do nothing if user asxed for nothing */ 



/* generalised section, initial! zation */ 

/ 



Buffer [e]--\e*s 
i-8; 

nyfile-KULi; 
reaove(Env Vers); 

/ 

/* parsing the input and execute each pair of paras V 

—*—**— — ««•*.«..««**.... / 

do { 



EnvVar - NUU; 

PronptString « NULL; 

do { 
i++; 

if (strlen(argv(ij) >■ siieof(Kwdl)) { 

if (!aemicm(argv(i)» Kwdl, siieof(Kwdl) • 1)) { 
st rupr (EnvVar ■ iergv{i j(sizeof(Kwdl) - 1]); 
continue; 

) 

} 

if (strlen(argv[i}) >■ si leof (Kwd2)) { 

if (Inenicnp(argv(i], Kwd?, sizeof(Kwd?) - 1)) { 
ProaptString ■ Sargv(i) [slieof (KwdZ) - 1]; 
continue; 

} 

} 





/• ok, something unenow had been entered, we <juit V 

^,l,Mtt**,H****,**»,*,******,*>*fl*IIMM«*,M«**ll**************l>*l>*l>*******^ 

pHntf(*Unxncwn keyword encountered, ’^s', Progrea ended.\n“,argv(i]); 
return; 

} vhile (((ProcptString •• NULL) II (EnvVar «■ KUll)) IS (i < (argc»l)}); 
if ((ProaptString •• KUll) II (EnvVar •• HULL)) { return;} 
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/ * * 

/* we found a peer (....) lets execute It and exit If an error occured */ 

If (r»qputenw(Er»vVer,PrwsptStrlng) !• 0) (breax;) 

) while (1 < (urge*])}; 



/*“'”** 

/* we did it, lets call it & day »/ 

/ — * * V 

If (qyfile !• NULL) (fclose(fflyfile);} /* be nice to a friend (OS/2) V 
return; 

) 

*** 

/* request the variable input and put it in the *Env Vors* file */ 

...... I / 

SHORT cdecl reqputenv(PCKAR EnvVar , PCHAR PronptString) 



CHAR vardata[256] ; /* input string for user */ 

SHORT re; 

prlntf("\n“); /• grab a new line V 

do { /* repeat until southing has been entered */ 

print f("(%s) %s:\EnvVar,ProKptString); /" pronpt the user */ 

gets(vardata) ; /* get the input from the user */ 

> while (strlen(vardata) •• 0); 

strupr(vardata); /• naxe it all uppercose V 

if fayfile «■ NULL) { /‘if not open, open the file */ 

ctyfi le«fopen(Env Vars,"w‘); 

) 

if (nyfile ■■ HULL) { f* if open went wrong, tell the world and quit •/ 
print f( "trouble with fopen"); 
retum(l); 

) 

sprintffBuffer^SET %s«%s\n“, EnvVar, vardat a); /* store the cconand */ 

rc»fwrite(0uffer.strlen(Buffer),l,pyfile): /* and write it V 

If (rc ■» 0) { /* if 0 bytes written, we have an error */ 

printf( ‘trouble with fwrlte"); 
retum(l); 

) 

retum(0); /* we are done with this one */ 

) 
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Appendix J. Sample Installation Code Diskette 

The following table shows the contents of the sample installation diskette. 



\REXXCMD\ 


\NETWARE\ 






L00P.CMD 


Figure 34 on page 74 




STARTPDI.CMD 


Figure 35 on page 76 




STARTRFB.CHD 


Figure 37 on page 78 




STARTRFI.CMD 


Figure 45 on page 91 




NMINST.CMD 


Figure 42 on page 86 




NNUPG13.CMD 


Figure 50 on page 98 




NKUPGRF1.CMD 


Figure 49 on page 98 




NNUPG.CMD 


Figure 51 on page 160 


\TCPIP\ 






NFSRFI.CMD 


Figure 17 on page 44 




TCPINST.CHO 


Figure 22 on page 49 




NFSRFIA.CMD 


Figure 24 on page 52 




CONNECT. CHD 


Figure 26 on page 57 




NFSPOI.CMD 


Figure 27 on page 57 




TCUPGRFI.CMD 


Figure 28 on page 59 




TCPUPG13.CH0 


Figure 29 on page 60 


\RIPL\ 






AUTOEXEC.BAT 


Figure 7 on page 31 




RIPLRFI.CMD 


Figure 5 on page 28 


\FDISK\ 






FOSK.OAT 


Figure 64 on page 162 




PIPE.CMO 


Figure 65 on page 162 




DISKPREP.CMO 


Figure 66 on page 163 


\RINSTPRN\ 




PRINTER. RSP 


Figure 68 on page 173 




RINSTPRN.HAK 


see page 177 




RINSTPRN.H 


see page 177 




R ERROR. H 


see page 179 




rTnstprn.def 


see page 186 




RINSTPRN.C 

R1NSTPRN.0BJ 


see page 180 




RESPONSE. C 
RESPONSE. OBJ 


see page 191 




RESPCHK.C 

RESPCKK.OBJ 


see page 203 




LOG.C 
LOG. OBJ 


see page 216 




RINSTMSC.C 
RINSTMSC.OBJ 
RI NSTDRV . OBJ 


see page 211 


\CREHWAR\ 




CRENWAR.KAK 


see page 214 




CRENVVAR.OEF 


see page 214 




CRENVVAR.C 

CRENWAR.OBJ 


see page 214 


\BIN\ 




RINSTPRN.EXE 

CRENVVAR.EXE 

REXINIT.EXE 






PRINTERS.CMD 


Figure 69 on page 174 



Figure 70. Contents of the Sample Installation Code Diskette 
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Glossary 



ANSI American National Standards Institute; 
U.S.-based organization which defines standards for 
computing devices, protocols, programming 
languages etc. 

Alias name. A redirected drive cannot be accessed 
directly. An Alias statement on the server points to 
the server directory or drive, which should be made 
accessible. Each Alias statement has a name, which 
must be referred to from a client workstation, when it 
wants access to this server directory or drive. 

API. Application Programming Interface; term used 
to describe the set of functions by which an 
application may gain access to operating system 
services. 

Bit. A binary digit, which may be either zero or one. 
Bits are represented within a computing device by the 
presence or absence of an electrical or magnetic 
pulse at a particular point, indicating a one or a zero 
respectively. 

Boot Manager. Feature of OS/2 V2.0 which allows 
multiple partitions to exist on fixed disks in the same 
machine, with a separate operating system on each 
partition. At boot time, the user may select the 
desired operating system with which to start the 
machine. 

Byte. A logical data unit composed of eight binary 
digits (bits). 

CD-ROM. Compact Disk Read-Only Memory; 
technology where data is stored on an optical disk for 
reading by a computer system equipped with an 
appropriate reading device. CD-ROM storage media 
may not be updated by the computer system, 
although certain implementations allow the media to 
be erased and re-written. 

CSD. see Corrective Service Diskette 

CSF. see Corrective Service Facility 

Corrective Service Diskette. To maintain OS/2 
operating systems, CSDs are supplied, which can be 
installed using the CSF. 

Corrective Service Facility. A mechanism of 
servicing the OS/2 product line. 

DDE. Dynamic Data Exchange; interprocess 
communication protocol used by applications to define 
dynamic links. Information updated in one application 
is automatically reflected in other applications linked 
to the first application via DDE. 



Debugging. The process of removing 'bugs' or 
errors from application code. 

Device Driver. Code which handles the translation of 
generic device commands into specific commands for 
the required physical device and vice versa, allowing 
operating system interaction with physical devices 
attached to the system. 

DLL. Dynamic Link Library; application module 
containing routines and/or resources, which is 
dynamically linked with its parent application at load 
time or runtime rather than during the linkage editing 
process. The use of DLLs enables decoupling of 
application routines and resources from the parent 
program, enhancing code independence, facilitating 
maintenance and reducing resident memory 
consumption. 

DMA. Direct Memory Addressing; technique by which 
transfers to and from system memory are made by an 
independent control chip rather than by the system's 
main processor, thereby resulting in improved overall 
performance. 

DOS. Disk Operating System; generally used in 
reference to IBM DOS, the single-tasking 16-bit 
real-mode operating system designed for Intel 8086 
processors, and developed by Microsoft Corporation 
as MS DOS in the early 1980s. IBM subsequently 
licensed MS DOS for use on IBM Personal Computer 
and Personal System/2 machines, and has since 
undertaken joint development of later versions of the 
operating system in conjunction with Microsoft. 

DOS settings.. Function provided by the Multiple 
Virtual DOS Machine component of OS/2 V2.0 which 
allows a user to customize the behavior of a virtual 
DOS machine to suit the application running in that 
VDM. Settings may be configured once by the user 
and saved, or applications may provide their own 
configuration information which is used by the VDM 
upon startup. 

DPMI. DOS Protected Mode Interface. 

EMS. Expanded Memory Specification; term used to 
describe the standard developed by Lotus, Intel and 
Microsoft for access to expanded memory by real 
mode 80x86 applications. 

Expanded Memory. Memory in 80x86 processors, 
typically on special hardware adapters, which is 
accessed by real mode 8086 applications using the 
LIM EMS specification. Up to 32 MB of expanded 
memory are supported by EMS Version 4.0. 

Extended Attributes. Under OS/2 V2.0 extended 
attributes are used to provide additional information 
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on files, programs and drivers. Under HPFS the 
extended attributes are stored together with the file. 
For file systems, not supporting extended attributes, 
the EAUTIL program can be used to extract the 
extended attributes from and storing them in a 
separate file, as well as reconstructing the original file 
with extended attributes. 

Extended Memory. Memory in 80286, 80386, and 
80486-based machines which is located above the 
1MB address boundary and accessed using the LIMA 
XMS specification. 

FAT. File Allocation Table; term used to describe the 
file system implemented by DOS and also supported 
by OS/2. This file system uses a file allocation table 
to contain the physical sector addresses of all files on 
the disk. The FAT file system is supported by OS/2 
V2.0, along with the newer HPFS and other installable 
file systems. 

GB. Gigabyte; 1024 Megabytes, or 1024 x 1024 x 
1024 bytes. 

HIMEM.SYS. The Extended Memory Manager in 
general use for DOS. 

HPFS. High Performance File System; file system 
first implemented under OS/2 Version 1.2, offering 
enhanced performance over the original FAT file 
system implemented in DOS and prior versions of 
OS/2. HPFS is an optional installation item under 
OS/2 V2.0; the FAT system may also be used to retain 
compatibility with DOS. 

Included response file. The keyword Include of the 
response file makes it possible to include another 
response file in a response file, thereby overriding 
keywords, previously defined before the include 
statement. 

I/O. Input/Output; term used to collectively describe 
the techniques and devices through which a computer 
system interfaces with storage devices, external 
systems and the user. 

KB. Kilobyte; 1024 bytes. 

LAN. Local Area Network: term used to define a 
group of devices (typically programmable 
workstations but also including midrange and host 
systems) known as nodes, which are located in close 
geographical proximity to one another (typically within 
a single property boundary), and which are connected 
in order to share and exchange information. Typical 
local area networks include the IBM token-ring 
network. 

LDU. LAN Download Utility: a NETBIOS utility for 
distribution of software across a LAN. 

LTS. The LAN transport system is used to establish a 
NetBios communication, basic vehicles are needed. 



The package of programs required to start a 
successful NetBios communication are called LTS. 

MB. Megabyte; 1024 Kilobytes, or 1024 x 1024 bytes. 

Multiple Virtual DOS Machine. Feature of OS/2 V2.0 
which enables multiple DOS applications to execute 
concurrently in fullscreen or windowed mode under 
OS/2 V2.0, in conjunction with other 16-bit or 32-bit 
applications, with full pre-emptive multitasking and 
memory protection between tasks. See also virtual 
DOS machine. 

NDM/2. NetView Distribution Manager/2: workstation 
product which interact with NetView DM on the host 
to provide change management functions. 

NETBIOS. NetBios stands for Network Basic 
Input/Output System for LAN. It is an Application 
Programming Interface (API) that allows high level 
communication programming on a LAN. 

Novell Netware. Novell Netware is a network 
operating system. 

Page. Granular unit for memory management using 
the 80386 and 80486 processors. A page is a 4 KB 
contiguous unit of memory, which the processor 
manipulates as a single entity for the purpose of 
memory manipulation and swapping. 

Physical Device Driver. Protected mode device driver 
used by the OS/2 V2.0 operating system and 
protected mode processes to access hardware 
devices. DOS applications running in VDMs do not 
directly access physical device drivers; virtual device 
drivers are utilized by these applications, and the 
virtual device driver in turn communicates with the 
physical device driver. 

POST. Power-On Self-Test; code typically stored on 
ROM (although the IBM PS/2 Model 90 and 95 allow 
POST code to be stored on fixed disk) which is 
invoked when a machine is powered on, in order to 
test the hardware. 

Protected Mode. Mode of operation for the Intel 
80286 and 80386/80486 processors, whereby the 
address space is expanded to 16 MB (80286) or 4 GB 
(80386/80486), and memory references are translated 
via segment selector and offset, enabling full memory 
protection between processes executing in the 
system. With the 80386/80486, paging is available in 
protected mode. 

RAM. Random Access Memory; term used to 
describe memory which may be dynamically read and 
written by a processor or other device during system 
operations. RAM is typically used to store program 
instructions and data which not being operated upon 
by the processor at the current moment in time, but 
which are required for the logical unit of work 
currently being carried out. 
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RAS. Reliability, Availability and Serviceability of the 
OS/2 operating system. 

Real Mode. Default mode of operation for the Intel 
80286 and 80386/80486 processors, and the only 
mode of operation for the 8086 processor. In real 
mode, the processor acts as a 16-bit device, its 
physical memory address space is limited to 1 MB, 
and memory references translate directly to physical 
addresses. With the 80386 and 80486, paging is not 
supported in real mode. 

Redirected drive. A drive letter, which is not pointing 
to a local logical or virtual drive, but to a drive or 
directory on a server. 

Response File. The response file is a man-readable 
ASCII file, prepared in advance, to answer all 
questions asked during the installation or 
maintenance of an OS/2 operating system by means 
of keywords. This file is used during the remote 
installation or maintenance process. 

REXX. Restructured Extended Executor: procedural 
language originally developed for VM/CMS, which 
conforms to the SAA standards for procedural 
languages as defined by SAA Common Programming 
Interface Procedures Language Reference , SC26-4358. 

RIPL. Remote Initial Program Load, the booting of a 
workstation from a server 

ROM. Read-Only Memory; term used to describe 
memory which may be read, but not written to, during 
system operations. ROM is typically used to store 
basic hardware initialization instructions, BIOS or 
self-testing code, which is required to be available 
prior to accessing the disk subsystem. 



SAA. System Application Architecture: set of defined 
rules, guidelines, interfaces and protocols for 
application and system design, intended to facilitate 
cross-system consistency and application portability. 

TCP/IP. Transmission Control Protocol/Internet 
Protocol. Provides the flexibility for network 
interconnection between different systems. 

VDM. See Virtual DOS Machine 

Virtual DOS Machine. A protected mode process 
under OS/2 V2.0 which emulates a DOS operating 
system environment, such that DOS applications 
executing within the virtual machine operate exactly 
as if they were running under DOS. DOS virtual 
machines support both text and graphics applications. 
VDMs make use of the virtual 8086 mode of the 80386 
and 80486 processors. 

Virtual 8086 Mode. Mode of operation of the Intel 
80386 and 80486 processors, which allows the 
processor to execute multiple concurrent tasks with 
each regarding the processor as its own distinct 8086 
processor. This mode of operation provides full 
pre-emptive multitasking and full memory protection 
between the virtual 8086 tasks. Also known as V86 
mode. 

80386. Intel 80386 microprocessor; the 32-bit 
processor upon which the OS/2 V2.0 operating system 
is based. 

80486. Intel 80486 microprocessor; a 32-bit processor 
which implements a superset of the 80386 processor 
instruction set. 
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A 

AltemateAdapter 118 

ARCHIVE keyword on CSF response file 111 

B 

BACKOUT keyword on CSF response file 111 
BaseFileSystem 118 
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Boot Manager 

Add partition to Boot Manager menu 152 
Add partition to utilize Boot Manager 152 
Change partition name for Boot Manager 152 
Default partition for Boot Manager 152 
Make startable for Boot Manager 153 
Restrictions when using 149 

c 

CDROM 118 
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